A Mozilla igazít a Firefox kiadási ütemtervén

Címkék

A Mozilla bejelentette, hogy 4 évvel a jelenleg érvényben levő kiadási ütemterve bevezetése után igazít azon. A cég az elmúlt négy évben a Train modellt követte, amelynek értelmében fix 6 hetente Firefox kiadás érkezett.

A mostani finomhangolás értelmében a fix 6 hetes ciklust egy kissé lazább, 6-8 hetes változ(tat)ható kiadási ciklus veszi át. Az új kiadási ütemtervvel a Mozilla éves szinten ugyanannyi kiadást tesz elérhetővé, viszont jelentős előnyei származnak a rugalmasabb kiadási ciklussal (például ünnepek idején csúsztathatnak).

A fentieknek megfelelően átalakított ütemterv erre az évre:

  • 2016-01-26 – Firefox 44
  • 2016-03-08 – Firefox 45, ESR 45 (6 weeks cycle)
  • 2016-04-19 – Firefox 46 (6 weeks cycle)
  • 2016-06-07 – Firefox 47 (7 weeks cycle)
  • 2016-08-02 – Firefox 48 (8 weeks cycle)
  • 2016-09-13 – Firefox 49 (6 weeks cycle)
  • 2016-11-08 – Firefox 50 (8 weeks cycle)
  • 2016-12-13 – Firefox 50.0.1 (5 week cycle, release for critical fixes as needed)
  • 2017-01-24 – Firefox 51 (6 weeks from prior release)

Részletek a bejelentésben.

Hozzászólások

Hatalmas ütemben fogyasztják a verziószámot!
Ez azért kellemetlen mert használok pár kiterjesztést amiben be van égetve az alsó és felső verziószám amivel működik. Már régen amikor még sokkal lassabban jöttek a Firefox frissítések átírtam néhányban a felső korlátot. Már régen túlhaladta az eredetit és most is hibátlanul működik, hiszen a jelenlegi verziószám ugrások zöme valójában normál esetben csak minor verzió lépés lenne.
Úgy látom lassan írhatom át újból a felső korlátot mondjuk 200-ra.
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

amikor tan a 7-es vagy 8-as korul jartak, es bepanikoltak a kromtol, akkor nagyon elszabtak a verzioszamozast...

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

Lehet olyanokat kellene hasznalni amiket karban is tartnak, szerintem ne a Mozzilat okoljuk mar ezert. Ha arra nem veszi a kedves developer a faradsagot, hogy 2-3 havonta egyszer leteszteli az uj verzioval, akkor csak gratulalni tudok.
Egyebkent meg van vmi LTS szeru hosszan szupportalt verzio is Firefoxbol, hasznalhatod azt.

Nem akarok neked rontani, de a 6 hét olyan messze van a 2-3 hónaptól mint Makó Jeruzsálemtől.
Másrészt: ha megírsz egy jó extensiont, akkor elég legyen már a github/egyéb issue tracking rendszerét nézegetned a hibák után.
Nem változik a firefox szinte semmit api szinten (de javíts ki ha tévednék) 5-10 verzióig.
Most jön majd egy nagy váltásuk, ami sutba vág jó pár extension-t, de cserébe talán 1-2 éven belül a gecko helyett lesz servo és browser.html (utód).
Ahogy olvastam a gecko -> servo átállást nem sietik el és a véletlenre sem bizzák. apránként váltják le majd a gecko komponenseket a servo komponensei.
Úgy érzem ezt már rég meg kellett volna lépniük, mert van pár oldal, ami hosszú másodpercekre megöli a böngészőt, betöltés közben is. És tisztában vagyok vele, hogy az oldal hibája, de egy Jira issue trackert vagy egy google drive-t nem fognak újra írni az biztos.

kollega irta "nem mehetsz a jelenlegi beta fölé", az meg nem tudom hany verzioval nagyobb a jelenleginel.
ha 6 het nem eleg, hogy ranezz egy projectedre annyira, hogy kiprobald es atirj benne 1 szamot, akkor az halott.
api akkor valtozik, amikor azt mondjak.
google drive nalam mukodik, most neztem ra("legszarabb i3-as laptop"), 1-2 secnel nem kellett tobbet varnom ahogy klikkelgettem benne.
igaz nekem nincs sok extensionom, es ff nightly-t hasznalok. 47.0a1

Pont tegnap teszteltem egy kiegészítőmet, amit elvileg át kéne írnom a többszálúsítás miatt, de simán ment a 46-os verzióval, ami most van elvileg beta-ban (ergo nem biztos, hogy minden kiegészítőt hazavágja az átállás, de nyilván nem árt migrálni abba az irányba majd).
Efölött van még az alpha, elvileg azt is be lehetett ixelni, hogy kompatibilis vele. Szóval ha minden igaz, 2-3 verzióval mehetsz a jelenlegi stabil fölé.

a beépülők életciklusairól beszélgetve a program fejlesztőjét szidni értelmetlen dolog (plugin vs mozilla fejlesztők). azért mert nincs alternatíva, mit foglalkozzon vele a mozilla kódoló? hol érdekli őt, hogy a programozók az általuk gányolt kódokkal nem akarnak foglalkozni, csak bezsebelni a tapszvihart. erre utaltam. (az más téma, és baromira nem ide keverendő, hogy a mozilla programozói is gyártanak barom kódokat)

--
xterm

Nem igazán értem miért probléma ennyire ez a verziószámozás. Ha valaki csinál egy extension-t és publikálja nincs ideje havonta 1x ránézni, hogy az újabb verzió elront-e valamit? Miért neked (az usernek) kell ilyen nevetséges mértékben feltolni a max verziószámot manuálisan?

Miért kell ezzel bárkinek foglalkoznia? A fent javasolt semver csak az egyik megoldás a sok közül. Pl. meg lehetne oldani a problémát kódanalízissel, ami automatikusan bumpolná a verziót ha adott extension nem használ olyan API-t ami breaking change-t tartalmaz. Vagy lehetne futtatni automatizált teszteket, hasonló eredménnyel.

Mert nem főverziót növelnek, hanem verziót. Nincs külön fő és alverzió, szerintem nem is nagyon van értelme egy böngészőnél. Talán kevesebb felhördülés lett volna, ha az ubuntuhoz hasonlóan valami könnyen emészthető dologhoz kötik a verziószámot (pl a kiadás dátuma).

Szükséges lenne a normális verziózós (lásd http://semver.org/) és ezzel együtt külön lehet választani a publikus (avagy marketing verziót) és a belső komponens és API verziózást. A jelenlegi helyzet az, hogy a beépülők és a többi kapcsolódó dolgok nem tudják egy darab számból eldönteni, hogy kompatibilis-e még az API-val vagy sem.

Ezzel nincs is gond, engem se érdekel, hogy melyik böngésző egészen pontosan milyen verziószámnál tart, de akkor is kell legyen egy belső verziózás, ami az M2M kommunikációban a kompatibilitási szinteket mutatja, különben káosz lesz (illetve Mozilla termékek esetén nem csak lesz: van) a beépülők és egyéb dolgok esetén, ha azok nem tudják eldönteni, hogy kompatibilis-e még a hívott API.

Ma is 3 részes verzió van, mert az FF44 az 44.0 (igen, pont nulla), a legutolsó pedig 44.0.1

Persze semmi értelme ennek, na nem mintha a jre8u73-nak több lenne. Na nem mintha a FF 3.x.y verziószámával bárkinek baja lett volna, valami agyhalott marketingest leszámítva.

A user a legritkább esetben találkozik a verziószámmal, a cucc frissül amikor kell neki, a verziót pedig nevezhetik 44-nek, kismacskának vagy épp dfg3453fsdt-nek is.
Csak legyen alatta egy stabil addon-API verziószám, ami csak akkor ugrik amikor tényleg változik.

Némi ellentmondást érzek (matematikailag). Ha 6 hetesről 6-8 hetesre térnek át, akkor bizony a kiadások darabszáma nem tud nem csökkenni (kivéve, ha váltoatlanul 6 hetes ciklus van). És lám, ott is van, hogy lesz 6 hétnél rövidebb ciklus.

Ez amolyan virtuális pöcsméret számháború?
Vagy csak elgurult a gyógyszer a marketing osztályon? :D

Egy értelmes verziószámnak szerintem tartalmazni kellene:

- major verzió:
ami azt kellene hogy jelense, hogy csak akkor növelik, ha komolyabb változtatás történik a szoftverben. Pl: API változás, kiterjesztések/kiegészítők nem működnek utána, durván új fícsörök kerültek bele, stb.

- minor verzó:
Bármilyen egyéb új release esetén

- release dátum
daily buldek esetén must have.

Ez utóbbi kettő igény szerint összevonható.

szerintem.

--
zrubi.hu

Mi a brandnak kell egy évre előre eltervezni hogy mi lesz? Az IT-ban azt sem lehet tudni, a holnap mit hoz...
Dolgozzanak inkább rajta. Pl. nekem még mindig rengeteget összeomlik. Lehet hogy a plugin hibás, na és? Akkor oldják meg, hogy a szar plugin ne rántsa magával az egész böngészőt. Lője ki, indítsa újra, vagy valami...
Nagyobb nyitva hagyott oldalaknál hosszabb időre vagy hoszabb ideig alvás/hibernálás után konstans 100% cpu használatot produkál, dolgozzanak inkább ezen, mert semmi de semmi változást nem látok verziók óta.
--
The Community ENTerprise Operating System