Az általam leggyakrabban használt Firefox verziója:

Szoftver

10.x
68% (366 szavazat)
9.x
11% (61 szavazat)
8.x
1% (6 szavazat)
7.x
1% (5 szavazat)
6.x
0% (0 szavazat)
5.x
0% (1 szavazat)
4.x
0% (2 szavazat)
3.x
8% (44 szavazat)
egyéb
10% (56 szavazat)
Összes szavazat: 541

( n4buk0d0n0z0r | 2012. 02. 06., h – 13:24 )

Seamonkey 2.7 játszik (motor: Gecko/20120129 Firefox/10.0) ?

Mától pedig ezt használom: Firefox/Aurora 12.0a2(2012-02-08), motor:Gecko/20120208 Firefox/12.0a.

Sokkal gyorsabb, mint eddig bármelyik browser és a memóriafelhasználása is optimalizált(értd. sok megnyitott lappal tart most 230 Mb-nál, ugyenezekkel a lapokkal a régebbi geckos böngészők 380-690 Mb-ot is elfüstöltek, egyedül a webkites Midori volt alatta, de az meg fapados).

( Hevi v | 2012. 02. 06., h – 13:30 )

Egyéb: nem gyakran használok Firefoxot.
(De amikor igen, akkor most épp valami 5-öst. Ahogy nézem, eléggé le vagyok maradva).

( pimpalaputty | 2012. 02. 06., h – 13:43 )

[irónia]Egyéb: passz, nem tudom követni, hogy éppen melyik verziónál a Firefoxom :)[/irónia]

( freeoli v | 2012. 02. 06., h – 13:53 )

Amióta ilyen erőszakos a ff update eljárása, szerencsére mindenki frisset használ.

( kedz v | 2012. 02. 06., h – 14:06 )

11.0

(pontosabban: 11.0~b1+build1-0ubuntu1 az Ubuntu precise-ben)

( traver | 2012. 02. 06., h – 14:14 )

Valóban, az erőszakos update miatt én is mindig a legfrissebbet használom, de tervben van az ESR, erre közel 200 gépet kell majd átállítanunk

( _Franko_ v | 2012. 02. 06., h – 14:33 )

Fogalmam nincs, ami éppen a disztribúcióban frissnek számít. :)

Ellenben kíváncsi vagyok, hogy mikor jön valami értelmesebb verziószámozás, mivel a konkurenciát beérte a Firefox, ha most továbbra is így tolják, akkor követhetetlen szám lesz a verizó, a plugin-kompatibilitás kiderítése pedig agyrém.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Ahja... én már csak ilyen ókonzervatív verzióbuzi vagyok, szeretem a verzióból kikövetkeztetni azt, hogy az adott szoftverben volt-e major vagy minor változás... ugyanis a verziószám alapvetően erre való, nem marketing okokból találták ki. Illetve ha marketing okokból bevezetnek egy könnyebben érthető és megjegyezhető verziószámozást, attól még megtartják belül a technikai verziózást, hogy a jövő ismerete nélkül tervezhető és implementálható legyen egy stabil működési tartomány...

Igazán kíváncsi vagyok, hogy a moduloddal hogyan tudsz előre egy stabil működési tartományt definiálni a jelenlegi verziózás mellett... mert az, hogy hónapokkal előre szólnak a _fejlesztők_ (sic!), az nem egy előre implementálható stabil működési tartomány...
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Ezek közül egyik se magyarázat arra, hogy miért nincs belső technikai verziózás, és továbbra se lehet előre megmondani, hogy melyik verziótól nem lesz kompatibilis egy API.

Tudod-e _most_ implementálni egy modulban azt a forráskódrészletet verziószám tartománnyal, amelyik jelezni tudja a verziószámból _előre_ az inkompatibilitást, azzal együtt, hogy előre nem ismert időpontban valamelyik _elkövetkező_ Firefox-ban változtatnak az API-n?
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Én ezt mond értem, de ezek mind-mind manuális és időrabló tevékenységek, az okosan használt verziószám viszont automatikus eszköz, pláne egy böngészőben lehet több alrendszer is külön-külön verziózva, a bundle verzió pedig megmaradhatna marketingeszköznek. Például van egy JBoss alkalmazásszerver, nevezzük JBoss7 néven, benne a moduloknak (Web, WebService, EJB, JPA, Messaging, stb.) külön verziói vannak, egészen változatos tartományban, így el lehet dönteni akár automatikusan is, hogy egy alkalmazás képes-e futni az adott szerveren vagy sem.

A Mozilla teljesen alárendelte a marketing szempontjainak a verziózását, amiből probléma volt a 3.x - 4.x váltásnál és probléma lesz a legközelebbi nem kompatibilis API változtatásnál.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Nem onnan allapitjuk meg, hogy tamogatva van-e valami vagy nem, hogy megnezzuk a bongeszo verzioszamat, hanem ranezunk, hogy letezik-e a feature.
Ha esetlegesen valaminek megvaltozna az API-ja, az uj namespace ala kerul emlekeim szerint - de lehet, hogy tevedek.
--
HUP Firefox extension

Hm... én továbbra is azt látom, hogy a Mozilla management sikeresen eliminálta a technikai verziószámok adta előnyöket, majd a keletkező problémákra mindenféle workaround megoldásokat és humán workflow lépéseket vezettek be, amelyekre nem lett volna szükség, ha bevezettek volna a technikai verziózás mellé egy marketing célú verziójelölést, mint ahogy azt IT világ okosabbik részén tették. Ennek a technikai verziózásnak egyébként semmi köze a fix release ciklushoz...
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

nem tagadom, hogy marketing okai (is) voltak a váltásnak, de talán jobban járunk vele mi webfejlesztők.

Ha fejlődnek a böngészők, és frissülnek folyamatosan talán nem fognak a felhasználók a verzióval foglalkozni. A chrome-nak pl egyáltalán nincs verizója. Legalábbis senkinek nem köti a chrome az orrára, hogy ő most a 14, vagy melyik. Persze az about-ban ott van, de pont az lenne ennek a rendszernek a lényege, hogy ne legyen verzió, ne lehessen ragaszkodni egy adott kiadáshoz, alap legyen a legújabb, és működjön minden ami eddig ment amellett, hogy működjön minden, ami később fog elkészülni. Lehet, hogy az FF nem jól csinálja, mert megmondja, hogy hányas verziónál tart, és nem csendben frissít, de az, hogy nincs kis és nagy kiadás az jó. Régen amikor volt, az emberek nem frissítettek IE6-ról 7-re, mert zavarta őket a lapsáv, ami új volt és szokatlan nekik. Amikor kijött a Firefox 3, nem frissítettek emberek, mert zavarta őket az előzmények lista megváltozása a címsávban. Arra kell törekedni, hogy a változások folyamatosak, egyenletesek, és apránként jöjjenek.

És hogy ez miért jó? Mert - bár a firefox már gyors kiadásokban tolja, sokan megakadtak a 3-as verziónál, ezért webfejlesztőként foglalkoznom kell külön velük.

És ha már az apit nézzük: a html, és a js a legjobb bizonyíték arra, hogy létezik olyan api, amit ha jól használnak, akkor azért fog működni jó sok kiadással később is. Talán nem a legjobb példa figyelembe véve a sok IE-re optimalizált, nem szabványkövető weblapot, és azt, hogy egy romhalmaz, amit próbálnak foltozni, de lehet jól csinálni.

Ha fejlődnek a böngészők, és frissülnek folyamatosan talán nem fognak a felhasználók a verzióval foglalkozni. A chrome-nak pl egyáltalán nincs verizója. Legalábbis senkinek nem köti a chrome az orrára, hogy ő most a 14, vagy melyik. Persze az about-ban ott van, de pont az lenne ennek a rendszernek a lényege, hogy ne legyen verzió, ne lehessen ragaszkodni egy adott kiadáshoz, alap legyen a legújabb, és működjön minden ami eddig ment amellett, hogy működjön minden, ami később fog elkészülni.

Úgy látom nem ment át a jónéhány hozzászólásom lényege: ha alapjaiban változik egy API -- például már támogatja az SPDY protokoll használatát, akkor ez nem derül ki jelenleg a verziószámból. A verziózásnak kialakult egy kultúrája, egy jó implementáció az OSGi, erről egy jó leírás a http://www.osgi.org/blog/2009/12/versions.html oldalon olvasható, egy bővebb leírás a http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf letöltésével olvasható.

Ettől teljesen független a vizuális verziózás, adhatnak az egyes verzióknak bármilyen kódnevet, szöveget, képet, ikont, videót, szagot vagy zenét... de ettől még egy viszonylag rövid és egyszerű verziózás szükséges dolog, különben káosz lesz a kapcsolódó rendszereknél.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

"A verziózásnak kialakult egy kultúrája"

Ez csak egy formája a verziózásnak. És el lett itt milliószor magyarázva, hogy ez miért rossz egy böngészőnél.

"ha alapjaiban változik egy API -- például már támogatja az SPDY protokoll használatát"

Oké, hogy változik alapjaiban egy API egy új funkció bevezetésétől? Mert ezt leírtad, de írhatnál konkrét példát is ami tud változni, mert nem tudom elképzelni, hogy az SPDY támogatás hogy jön ide. Nyilván lesznek plusz függvények, metódusok, annyakinnya, de attól még nem szükségszerűen fog megváltozni az, ami már létezik. Szóval tényleg mondj olyan konkrét példát, mert lehet félni attól, hogy lesz ilyen, de a gyakorlatban meg az látszik, hogy a chrome-nál minimum verzió van csak, és nem okoz problémát az extensionok fejlesztése pedig ők is gyorsan verzióznak.

Ez csak egy formája a verziózásnak. És el lett itt milliószor magyarázva, hogy ez miért rossz egy böngészőnél.

Bocsánat, de miért is _rossz_ egy böngészőnél, ha egy plugin azt látja, hogy 3.9.7, a felhasználó meg azt látja, hogy "Firefox Szagosmüge edition 2014"?

Az SPDY egy példa volt. Mondhatok olyan példát is, hogy jogi viták miatt ki kell venni az XYZ szabvány támogatását. Hogy magyarázod el a plugin felhőnek, hogy ma még jó a Firefox 43, holnap már nem jó az új Firefox 44? Mert leghamarabb a telepítésnél, legkésőbb a futásnál egy szép kövér hanyatt esést produkál majd a böngésző vagy a plugin... persze lehet sok megoldást alkalmazni, a kényelmes és kitaposott út a belső technikai verziószámozás...
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Mint plugin fejlesztő (extension, nevezzük nevén, feltéve ha azokról beszélünk) te érdekelt vagy abban, hogy a munkád a későbbiekben működjön, ezért figyeled a megfelelő csatornákat. Ez a verziózási rendszertől független.

A firefoxnak van 3 kiadása. Egy kísérleti, egy béta, és egy éles. Az élest használják a felhasználók, a kísérletibe kerülnek be az új dolgok, a bétába meg lehet tesztelni. Tehát neked, mint fejlesztőnek két kiadás előnyöd van letesztelni a programodat, és felkészülni a változtatásokra. Már ha aktívan fejleszted az extensiont. Ha nem, akkor egyébként is le fog állni a működése, miután elérte a max verziót, amit belőttél neki.

A jogi kérdés rossz példa. Azt nem időzítheted a következő nagy kiadásra. Ha egy szabvány támogatását meg kell szüntetned, akkor gondolom kénytelen vagy kivenni függetlenül attól, hogy hol jársz a kiadási ciklusban, a következő verziótól. Akkor se tudsz semmit se tenni. Ráadásul a böngésző készítője sem. Ha kiadja következő egész számú verziót akkor az extension nem fog elindulni, mert beállítottad, hogy ott már ne menjen, vagy hibázik, de előfordulhat, hogy egyébként közel funkcionálisan működik.

De amúgy ez is egy erőltetett példa, ugye hogy nehéz egy életszerű példát hozni? Bármi ami eszembe jut az inkább hozzáad, vagy ne adj isten módosít a mostanin, de módosítani lehet úgy, hogy ne sértse a régit.

Régen egyébiránt mi volt? Extensionök tömegei nem működtek új ff kiadás után közvetlenül amíg az author nem frissítette az extensiont. Olyanok is, amik egyébként működtek volna, csak a max verziót kellett átírni.

Az, hogy miért rossz, ha a felhasználó más verziót lát mint a belső verziózás. Ilyet nem mondtam. Az a rossz, ha az emberek fő és al verziókban gondolkodnak, mert amíg így teszik, addig mindig lesz az az egy verzió, ami nagy változásokat hoz, félve lépik meg, lemaradnak a felhasználók annál a verzióvonalnál, és nekik külön supportot kell nyújtani.

Fel kellene oldalon az ellentmondásokat a hozzászólásodban. Van három nagy ellentmondás:
"érdekelt vagy abban, hogy a munkád a későbbiekben működjön, ezért figyeled a megfelelő csatornákat"
vs
"Extensionök tömegei nem működtek új ff kiadás után közvetlenül amíg az author nem frissítette az extensiont"

"Tehát neked, mint fejlesztőnek két kiadás előnyöd van letesztelni a programodat, és felkészülni a változtatásokra"
vs
"Ha egy szabvány támogatását meg kell szüntetned, akkor gondolom kénytelen vagy kivenni függetlenül attól, hogy hol jársz a kiadási ciklusban, a következő verziótól."

"Bármi ami eszembe jut az inkább hozzáad, vagy ne adj isten módosít a mostanin, de módosítani lehet úgy, hogy ne sértse a régit."
vs
"addig mindig lesz az az egy verzió, ami nagy változásokat hoz, félve lépik meg"

Nekem ebből ez jön le: tudod, hogy nem jó, de valamilyen rejtélyes okból próbálod védeni a rossz megoldást.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

"érdekelt vagy abban, hogy a munkád a későbbiekben működjön, ezért figyeled a megfelelő csatornákat"
vs
"Extensionök tömegei nem működtek új ff kiadás után közvetlenül amíg az author nem frissítette az extensiont"

Ez nem ellentmondás, az egyik arról szól, hogy mit kéne tenni, a másik az, hogy milyen (volt) a gyakorlat. A komolyabb fejlesztők akkor is igyekeztek kiadásra készre tesztelni a plugint bizonyára.

"Tehát neked, mint fejlesztőnek két kiadás előnyöd van letesztelni a programodat, és felkészülni a változtatásokra"
vs
"Ha egy szabvány támogatását meg kell szüntetned, akkor gondolom kénytelen vagy kivenni függetlenül attól, hogy hol jársz a kiadási ciklusban, a következő verziótól."

Ez csak akkor ellentmondás, ha annak akarod érteni. Írtál egy rendkívüli helyzetet. Az esetek nagyrészében viszont egy változtatást nem kell hirtelen elintézni, végig tud futni a kiadási cikluson, és akkor van idő reagálni rá.

"Bármi ami eszembe jut az inkább hozzáad, vagy ne adj isten módosít a mostanin, de módosítani lehet úgy, hogy ne sértse a régit."
vs
"addig mindig lesz az az egy verzió, ami nagy változásokat hoz, félve lépik meg"

Ebben hol az ellentmondás? Én a felhasználókról beszéltem az utóbbi mondatban. Amikor nagy kiadások vannak, a felhasználók félve lépnek a következőre. Például amikor az FF3 kijött, sokan nem váltottak a kettesről.

Nekem ebből ez jön le: tudod, hogy nem jó, de valamilyen rejtélyes okból próbálod védeni a rossz megoldást.

Rosszul jött le :) Én nem gondolom, hogy rossz a mostani megoldás. Sőt, jobb mint a régebbi. Webfejlesztőként így értékelem. Felhasználók szempontjából is jobbnak tartom. Lehet, hogy a kiterjesztések fejlesztői részéről kicsit több odafigyelést igényel.

"A Mozilla teljesen alárendelte a marketing szempontjainak a verziózását"

És szerintem egy oriási nagy marketing fegyvert kiütöttek a kezükből egyúttal, ld. release party, mindenféle csudamarketing event ("tölsük le minél többen 24 óra alatt", stb.), ami véleményem szerint kicsit nagyobb hírverést csinált neki, mint egy "megjelent a firefox n+1. verziója" című rövid hír.

----------------
Lvl86 Troll

( pacm4n | 2012. 02. 06., h – 14:34 )

Egyéb: Mozilla Firefox-Trunk 13.0a1

=Λ=

( BlinTux v | 2012. 02. 06., h – 15:20 )

Egyéb: FF csak tesztelési célra van fent, mindig a legfrissebb stabil verzió. Böngészésre nem használom.

( carlcolt | 2012. 02. 06., h – 15:43 )

Inkabb Seamonkey-t hasznalok es akkor van a bongeszomben IRC es email kliensem is, ugy cakkunpack.

( samu.ferenc | 2012. 02. 06., h – 15:53 )

Esetleg lehetett volna egy olyan, hogy "mindig az aktuálisan friss verzió"

( bra | 2012. 02. 06., h – 16:05 )

50.2.
Meguntam, hogy állandóan frissítgetni kell, letöltöttem a forrást, átírtam kézzel, így most pár évig nyugi van.

( current88 | 2012. 02. 06., h – 18:05 )

Csak akkor használom a nehézkes ff-ot, ha muszáj, inkább a chrome-ot használom.

+1
mivel soha nem futtattam a 3dmark browser-es megfelelőjét (így azt se tudom van-e ilyen valójában), fogalmam sincs mikor/hol/miben gyorsul (ha egyáltalán). Azért az elmondható h. valamivel mintha jobb lenne a sebessége mint a korábbiak, mondjuk 1 évvel ezelőtti. Persze ha sok a kép/flash akkor core2 duo ide vagy oda, megröccen... vagy a szkrollozáskor is. Úgy rémlik valamikor 1999 környékén még nem volt gond a smooth szkrollozással egy 1/10 teljesítményű CPU-val, és 1/10 teljesítményű VGA-val. A flash videók talán 2007/8 környékén kezdtek el akadni, azelőtt windóz XP-vel szintén core2 gép integrált intel VGA sosem szaggatott. Pedig ma már elvileg VGA-ból megy a desktop kompozisön! Így múlik el a világ dicsősége.

Ami nem tetszik...

Resident set size-nál:

711.82 MB (93.05%) -- anonymous, outside brk() [rw-p]

Virtual size-nál:

5,517.34 MB (89.42%) -- anonymous, outside brk() [rw-p]

Az összes virtuális memóriafoglalás 6.17 GB, miközben a fizikai RAM 2 GB. Azt hogyan lehet kideríteni, hogy melyik extension-ben van memleak? Mondanom sem kell, a böngésző már kezd lassan reagálni. Az egyik gyanusítottam simán a Hupper.

tr [:lower:] [:upper:] <<<locsemege
LOCSEMEGE

( Breaknet | 2012. 02. 06., h – 21:36 )

A 10 nagyon-nagyon jó lett. Hihetetlenül stabil, egyszer nem fagyott, omlott és villámgyorsan rendereli az oldalakat.

( T_chris | 2012. 02. 06., h – 21:40 )

Ritkán használom mostanában, mivel W8 IE-t használok, de ha kell akkor a legfrissebbet töltöm le...
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - -> Kérjük a humoros aláírást itt elhelyezni. <- - -

( mogorva v | 2012. 02. 07., k – 10:02 )

Kimaradt a "Mindig a legfrissebbet" opció.