What do devs think of Mozilla's quickfire release schedule?
Jó ez a gyorsiramú verziókibocsátás?
■ 
Friss blogmarkok
- Web Akadálymentesítési Útmutató (WCAG) 2.1 – nyilvános munkaterv – Megjelent a WCAG (Web Akadálymentesítési Útmutató) 2.1 nyilvános munkaterv (0)
- MongoDB Apocalypse Is Here as Ransom Attacks Hit 10,000 Servers – Több tízezer védtelen MongoDB szerverre csaptak le hackerek (2)
- 12 Signs You’re Working in a Feature Factory – A cél nélküli funkciógyártás néhány tünete (0)
- Translatable, custom dates in Twig templates of Drupal 8 – Saját dátumok megjelenítése, fordíthatóan a Drupal 8 smink rétegével dolgozva (0)
- NativeScript – Cross-Platform Native Development with Javascript – Fejlesszünk natív mobilalkalmazást JavaScripttel (0)
- GitHub Security Update: Reused password attack – Érdemes bekapcsolni a kétfaktoros azonosítást, ha a GitHub jelszavunkat más oldalakon is újra felhasználtuk (17)
- UX Design könyv – Hogyan tervezz felhasználóbarát és szerethető alkalmazásokat? (0)
- Introducing unlimited private repositories – Megváltozik a GitHub díjszabása: minden előfizetéshez korlátlan számú privát repository jár (0)
- Drupal 8 Twig: add custom CSS classes to menus (based on menu name) – Saját elképzeléseink szerinti CSS osztályok (automatizált) hozzáadása a Drupal 8 menüihez (0)
Cikkajánló
Nagy Péter:
Több PHP beállítása egy Windows rendszeren
janoszen:
Nagy terhelésű rendszerek fejlesztése 3.
Hojtsy Gábor:
2004 - egy év a web körül II.
Friss csiripek
Csiripek betöltése…
Aktív fórum témák
Új fórum témák
Archívum
| H | K | Sze | Cs | P | Szo | V |
|---|---|---|---|---|---|---|
| 25 | 26 | 27 | 28 | 29 | 30 | 1 |
| 2 | 3 | 4 | 5 | 6 | 7 | 8 |
| 9 | 10 | 11 | 12 | 13 | 14 | 15 |
| 16 | 17 | 18 | 19 | 20 | 21 | 22 |
| 23 | 24 | 25 | 26 | 27 | 28 | 29 |
| 30 | 31 | 1 | 2 | 3 | 4 | 5 |
…fel van fújva…
Hát a When can I use...
Én inkább arra volnék kíváncsi, hogy ha minden apróságért a főverziószámot növelik, mivel jelzik majd ha egy lényegesebb változástatást végeznek? Esetleg 10-el növelik a főverziószámot?
Gondolom a kiegészítő íróknak is alaposan keresztbe tehettek. Mert eddig ha beírták, hogy <em:maxVersion>6.*</em:maxVersion>, akkor tudták, hogy a következő lényeges változtatásig használható. De most lehet 2 hét múlva már inaktiválja a böngésző a kiegészítőt, mert egy apró változtatás miatt (vagy csak mert az ütemterv úgy kívánja) a verzió 7.0 lesz, pedig ha a változtatás mértékének megfelelően 6.0.1 lenne, akkor minden simán mehetne tovább.
Ez történik akkor, ha a
Nem mondanám, hogy pusztán
Persze nyilván marketing fogás is, de ahol verseny van, ott az is számít.
Én egy fő verzióváltástól
Ezzel elerodálják a verziók értékét, kicsit hasonlít a mesére, amikor a kismalac rókát kiált háromszor, pedig az nem is jött, amikor meg valóban ott megérkezik elfogyasztani, az emberek nem hisznek negyedszerre, és nem segítenek neki.
Emellett a szűk határidők frusztrálhatják is a fejlesztőket, nagy a nyomás rajtuk, esetleg kevesebbet tudnak csak tesztelni, szóval azért lehetnek hátrányai is.
Újdonságok
Például az érintés események, valamint a WebSockets újra engedélyezése szerintem elég lényeges különbség, legalábbis fejlesztői szempontból. Hogy ezek létét vagy hiányát közvetlenül nem veszi észre az átlagfelhasználó, az egy dolog.
Te milyen újdonságokat vársz egy új főverziótól?
A szűkebb határidők meg nem vészesek, ha megfelelő mennyiségű újdonságot és javítást kell megvalósítani.
Személy szerint én annak is örülök, hogy nem évente kapok egy szinte teljesen más böngészőt, hanem szépen, folyamatosan, ápránkét változik a program, és (könnyebben) tudom követni az újdonságokat. Ez kiváltképp jó lehet a kevésbé számtech orientált felhasználóknak. Valamint fejlesztői szempontból sem utolsó, ha nem kell egy évet várni, hogy egy új, hasznos funkció megjelenjen, hanem amint megfelelően stabil állapotba kerül, ki tudnak adni egy új verziót vele.
Nekem nem a verzióváltással
Sőt, továbbmegyek, vegyük például a HTML 5-öt: a fejlődés és az új dolgok elhanyagolhatóak (még ha az ellenkezőjét is sulykolják), valamint az egész tíz évvel le van maradva, hogy nem érdemelne többet 4.1-nél. Dehát valamivel igazolniuk kell magukat a W3C-nél, hogy dolgoznak.
Ha a Windows-t és az Office-t
De remélem nem azt akarod mondani, hogy szerinted csak az ér meg új főverziót, ha átrendezik a felhasználói felületet. Főleg egy olyan szoftverben, ahol a többség csak úgy használja, hogy a kezdőlapnak beállított keresőbe beírja, hogy hova szeretne menni, aztán csak klikkelget a weboldalakon (amiknek a színfalak mögötti, minél jobb, hatékonyabb, egyre sokrétűbb működtetése az egyik fő feladata).
Az pedig nem kis költői túlzás, hogy az FF2 és az FF4 felhasználói felülete és az általuk nyújtott felhasználói élmény közel azonos. Meg aztán ami hatékony, és jól működik, azokat a részeket kár lenne marketing szempontok miatt túlságosan átvariálni, hogy érdemessé váljon egy új főverzióra ;)
Szerintem ne keverjük bele,
Mivel egy böngésző felülete túl sok elemből nem áll, és már most is a lehető legkevesebbet kapjuk, szerintem új fő verziót az érne meg, ha mondjuk 100%-ban támogatná a HTML5-öt és a CSS3-at. Mert tedd a szívedre a kezed: az általad linkelt oldalon található fejlesztések szerinted megérnek egy fő verziót? Mert nekem ezek eléggé csak hibajavításoknak tűnnek.
Én inkább azon a véleményen
Úgy gondolom, a verziószám inkább csak marketing eszköz. Fejlesztői szempontból csak annyit számit, hogy tudd, az adott verzióban milyen lehetőségek érhetőek el, és hogy a készített szoftver célcsoportja számára elérhető-e az adott verzió. Ha majd (a csendes frissítések elterjedésével) feltételezhetjük, hogy a felhasználók többsége az éppen legfrissebb verziót használja, már teljesen mindegy lesz, hogy azt milyen néven vagy számon emlegetjük.
Felhasználói élményhez még hozzátenném, hogy ezen a téren én vettem észre jelentős változásokat Firefoxnál. Itt pédául a híresen lassú indulására célzok, vagy a memóriafogyasztásra, amire a 4.0-s verziótól kezdődően elég nagy hangsúlyt fordítanak. Korábbi kiadásokhoz képest már most is elég jó a helyzet, de a 7.0-s verzióra akár fele akkora memóriafogyasztást terveznek, ami ha sikerül, megintcsak jelentős mérföldkő felhasználói élmény tekintetében (pláne lassúbb gépeken).
Az igaz, hogy az 5.0 vagy 6.0 nem hozott annyi újdonságot, mint mondjuk a 4.0, de egy olyan gyorsan változó, fejlődő (?) platformon, amire a böngészők épülnek, felesleges ekkora fontosságot tulajdonítani fő vagy alverzióknak. A lényeg, hogy minél előbb elérhetőek legyenek az újdonságok vagy a szoftver működését javító fejlesztések. Ha a Mozilla ezt így tudja elérni, ám legyen.
[szerk]
Igen, egy hagyományos, fix környezettel/környezetben működő asztali alkalmazáshoz kevésnek tartanám a fentieket egy új (fő)verzióhoz.
[/szerk]
Kiegészítők
Arról nem is beszélve, hogy az ilyen döntéseket, új verziókban megjelenő változásokat, stb. elég jól dokumentálja a Mozilla, így akinek számít, az könnyen figyelemmel tudja kísérni, és tud rá készülni :)
+1, -1
Viszont azt sem szabad elfelejteni, hogy Firefox győzelmének másik alappillére, és vonzereje még most is, a temérdek szuper kiegészítő. Utóbbiak normális karbantartását viszont gyakorlatilag lehetetlenné teszi ez a főverzió dobálás.
Engem nem zavar, hogy reklám célból dobálják a főverziókat, de legyen mondjuk egy API verzió szám is, amihez lehet igazítani a kiegészítőket.
Egyébként ha már marketing, akkor elgondolkodhatnának a fantázianeveken is, akár úgy mint az Ubuntu: ÉÉ.HH. Fantázianév
Ami a fantázianevet illeti,
Példa?
Meg is tudnád indokolni, hogy miben teszi lehetetlenné a kiegészítők karbantartását?
Én mint kereskedő tudom mi