I tak będzie potem trzeba łatać.
Ale ja już teraz nie mam zdania.

Argumentem za jest, że to duże wydanie Eltena, a więc dobrze, by było napisane w najnowszej wersji Rubiego. Zwłaszcza, że Ruby 3.0 to naprawdę ważna aktualizacja.
Ta wersja jest 3x szybsza ponoć, ale to mniej ważne, bo i tak program jest tak szybki, jak szybki jest jego kod przede wszystkim, a środowisko to cecha dużo mniej istotna.
Ważniejsze dla mnie są konkretne nowości wprowadzane przez Rubiego 3.0, jak wymuszanie typowania zmiennych czy ciągi binarne, które pozwalają manipulować danymi binarnymi bezpośrednio, nie jako napisami.
Ale najważniejsze, i główny argument dla którego się nad sprawą zastanawiam, to masa nowych narzędzi do sprawdzania kodu, jego kompilowanie bez uruchamiania itp. Wierzę, że pozwoliłoby to na bardzo znaczne ulepszenie jakości prac nad Eltenem, gdybyśmy rzeczywiście z Issue Trackingiem przenieśli na GitHuba.

Argumentem przeciw jest, że i tak zwykły użytkownik nie zauważy różnicy, a i tak premiera jest już przesunięta o 5 miesięcy względem planów.

Oczywiście zawsze można przesunąć premierę, jak kiedyś ktoś sugerował, aż na 24 sierpnia, nadać nowej wersji numer 3.0 i ją przebudować, ale tego raczej społeczność nie wybaczy. :D

Napisz bardziej o ile spowolni pracę twoją wydanie najpierw wersji 24 stycznia, a potem aktualizacja do ruby 3.0, chociaż pewnie ciężko to przewidzieć.
Jeśli by poraz kolejny musiała być przełożona premiera, to użytkownicy by musieli coś dostać. a no i pytanie o ile byś chciał opóźnić premierę?

Chciałbym opóźnić ją o miesiąc albo dwa.
Jak wydam Eltena 2.4, raczej nie będę już portował do Rubiego 3.0, zbyt dużo nowości, prac i zmian. Raczej wtedy by kolejne wersje działały na 2.7 aż do następnego big release. To nic dziwnego, Elten 2.3 działał na Ruby 2.5, choć już wydany był 2.6 i 2.7, dopiero Elten 2.4 przeskoczył na 2.7. Stąd m.in. niekompatybilności kodu.

Ciekawe kiedy język interpretowany się kompiluje.

Zawsze, w momencie wykonania albo zapisu w formie pośredniej. Proponuję zapoznać się z procesem, zanim się zacznie mędrkować, bo jest to niepotrzebne.
Ruby potrafi dekompilować i kompilować swoje klasy w celu ich analizy albo zapisania w kodzie pośrednim celem szybszego załadowania.
No i jest cały moduł JIT, choć Elten jeszcze go nie używa.
https://blog.heroku.com/ruby-just-in-time-compilation

No i co z tego, to tylko kod bajtowy jakiś, który i tak nigdy nie jest taki sam jak n o r m a l n y program w n o r m a l n y m języku jak C czy c++

Masz ciekawą definicję normalnego języka, z którą jednak większość programistów by się w tych czasach nie zgodziła. Koniec tematu, to nie jest wątek o tym.

Zawsze znajdzie się coś, co w sumie warto wdrożyć itd. Możed zamiast co dwa lata czy tam trzy strzelać z grubej rury taaką porcją nowości, jakieś dwa miesiące wszystkiego na becie i jeśli zadziałą to przenosić do stabilki? Znowu mamy sytuację, w której użytkownicy mają dylemat, bo z jednej strony beta już ma takie fajne różne nowości, z drugiej cóż... beta to beta i zawsze może wylecieć w powietrze. To może fajnie brzmi, jak co czas jakiś można w liście zmian dać tyyle tego, jednak może mimo wszystko lepiej to, co już działa to zwyczajnie przenosić do stabilki. Może to mniej medialne, ale chyba jesteśmy tak małą grupą, że chyba nie trzeba tutaj taakiego szoł robić. Za to w świat można co jakiś czas puszczać info, że tyyle nowości jest i wbijajcie, kochani, wbijajcie.

Tak można postępować przy większym zespole, który może w taki sposób pracować. Nie gdy jest jedna osoba, i np. wciąż są problemy z dodatkiem, trzeba kordynować tłumaczenia, zmiany na serwerze itp.

Nie ma problemów z dodatkiem. Julitce nie działają linki, ja nadal nie rozmiem w jaki sposób, bo mi wszystko działa.

jestem za 24 stycznia, mimo wszystko

Ja również

Ja też

Ja też

Jak dla mnie pomysł z Eltenem 3.0 jest sensowny, szczególnie że rzeczy nowych jest sporo.

poczekaj na nową wersję rubiego.

Dokładnie.

Jak wszyscy to wszyscy