A szoftverek verziószámozása, annak mikéntje (major, minor stb.) ... kérdés.

Címkék

lényegtelen kérdés (fejlesztő vagyok)
4% (22 szavazat)
nem különösebben fontos kérdés (fejlesztő vagyok)
16% (80 szavazat)
fontos kérdés (fejlesztő vagyok)
30% (146 szavazat)
lényegtelen kérdés (felhasználó vagyok)
5% (25 szavazat)
nem különösebben fontos kérdés (felhasználó vagyok)
18% (88 szavazat)
fontos kérdés (felhasználó vagyok)
17% (81 szavazat)
Egyéb, leírom.
1% (6 szavazat)
Csak az eredmény érdekel.
8% (41 szavazat)
Összes szavazat: 489

Hozzászólások

"End-user alkalmazásoknál viszont elég nehezen értelmezhető a "visszafelé nem kompatibilis módosítás" fogalma"
Miért is?

A visszafelé nem kompatibilis változás az, ami a felhasználót (legyen az API felhasználó, vagy end user) pluszmunkára kényszeríti a változás miatt.

Ami eddig működött X módon, ha a user egy adott lépéssorozatot csinált, most meg Y módon működik, akkor az visszafelé nem kompatibilis változtatás.
Például: eddig egy módon renderelt egy bizonyos docx-et, majd az új verzióban meg másként. Ez bizony visszafelé nem kompatibilis változás user szempntból. Mert mondjuk eddig úgy volt elkészítve a docx file, hogy helyesen jelenjen meg. Most meg nekiállhat vele dolgozni a user, hogy az új rendering engine mellett is helyesen jelenjen meg.

Ami csak probléma az usernek, ha utána akar nézni valaminek, és két különböző számozást lát, és nem éti mi van.

Kérdés az, hogy a Visual Studio 2015 és a 14 között van-e különbség. Ha nincs, akkor miért nem 2015 a fejlesztői verzió számozása?

+1

Amit meg a bngészők játszanak a verziószám versennyel, az röhej.
Monsjuk a random verziózással jól lehet szivatni a Debian féle disztibeket :)
És nem szégyen ha egy program évekig azonos major verzión van. Sőt. Egy olyan verziószám, hogy 2.98.5 Azt sugalja, hogy komolyan veszik a fejlesztést, gyakran frissítenek, miközben odafigyelnek azokra akik használják a programot.
A 42.1 Azt mondja, hogy bleeding edge.
a 2015, azt hogy "idén ez van".. jövőre meg.

Az ide-oda váltogatás meg őrület. meg amikor funkciókat jelölnek vele.
Photoshop 1,2,3...6,7,CS,CS2,CS3...CS5,CS5.5(van 3D),CS6(nincs3D),CC,CC2014,CC2014.1..,CC2015

### ()__))____________)~~~ ########################
# "Do what you want, but do it right" # X220/Arch

miert nem lehet az elso kiaadast 1.x verzioval jelolni ?

tudtad, hogy az informatikaban 0-val kezdodik a szamozas?

--
"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)

Az index nem sorszám (tömbindexnél, listánál), hanem offszet az első elemhez képest. Ezért az első elem (aminek a sorszáma 1), annak az indexe 0.
Persze ezt sokan úgy fogják fel, hogy az első elem sorszáma 0. Nem, azt kéne felfogni, hogy a tömb index az nem sorszámot jelöl, hanem offszetet.
Ezért keződik 0-val. Nem 0-tól sorszámozunk, hanem 0-val indexelünk. Van különbség. A tömb első eleme 0 indexű. Attól még az első az első, azaz 1.

ez kicsit mintha mellement volna. Szoftver verzioszamok kontextusaban nem tunik jo otletnek bedobni az index, tombindex, lista, elso elem, offstet es hasonlo koncepciokat...

--
"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)

>>>> miert nem lehet az elso kiaadast 1.x verzioval jelolni ?
>> tudtad, hogy az informatikaban 0-val kezdodik a szamozas?

Szerintem ennek nincs jelentősége. Az első kiadás ettől még lehet 1, hiszen a nullát használod a nulladik kiadásra, tehát amikor még nincs kiadva a szoftver.

Egyébként érdekes dolog azt mondani hogy az első kiadás verziója legyen 1, hiszen a verziószám nem azt jelöli hogy hányadik kiadás. Az 1.1 is egy kiadás, tegyük fel a második kiadás, de akkor miért 1.1, miért nem 2? :)

Abban viszont van logika hogy az első kiadás legyen 1. Az előtte lévő nem kiadások verziózása pedig 0.x. Abban nincs hogy évek óta fejlesztett, használatban lévő szoftverek nem tudnak nullapontvalahány fölé jutni.

ugy latszik, te sem hallottal meg errol a koncepciorol: https://en.wikipedia.org/wiki/Software_versioning#Version_1.0_as_a_mile…

--
"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)

"nem különösebben fontos kérdés (fejlesztő vagyok)" 13% 6 szavazat

"lényegtelen kérdés (fejlesztő vagyok)" 9% (4 szavazat)

Úgy tűnik, hogy van a hup.hu-n legalább 10 ember, akit semmilyen körülmények között nem vennék fel a cégembe.

Ha van egy nagy project-ed, akkor általában két megközelítést alkalmazhatsz:

1) Csinálsz egy nagy monolitikus repót, és a kód újrafelhasználás copy-paste-ként jelenik meg a repók között.

2) A projecteket több kis project/library integrációjából rakod össze, elkerülendő a kódok duplikálását.

Namost, ha a második metódust űzöd, akkor a szemantikus verziózás nehezen kerülhető el. Hiába a végterméked applikáció.

pl tipikusan egy weboldalnak nincs verzio szama, de sok ilyen "rolling release" szoftver van (pl belso hasznalatra), amibol gyakorlatilag csak 1 verzio letezik.
A masik baj, hogy ehhez mindenki ert, hogy hogyan kellene elnevezni es innentol kezdve csak macera ezen ragodni. Vki nevezze el, aztan hasznaljuk azt. Az mar teljesen mindegy hogy 9.4 vagy 9.4.3 vagy 9.4.3.12323 vagy 9.213232 stb. ha nem szamit a foverzio onnantol kezdve lehet ubuntu szeru is pl (youtube-dl).

(x) Egyéb, leírom: nagyon fontos kérdés (devops vagyok). Sikítófrászt tudok kapni, a hülye verziózástól.

Az Ubuntu verziószámozása nekem tetszik. (16.04.x)
Csak a nevüket nem tudom megjegyezni. :(
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

Ha a verziószámozást mindenki úgy végezné, ahogy azt elméletileg kell, akkor fontos kérdés lenne. Azonban a gyakorlatban hatalmas nagy kupleráj van, így sajnos sok esetben félrevezető.

Ok. Nem fogalmaztam pontosan. Arra gondoltam, hogy van néhány elterjedt módszer, és azok közül választana az adott szoftver fejlesztője. Akkor ez már némi támpontot nyújtana. (Pl.: semantic versioning)

Rengeteg olyan program van ami már évek óta jól használható, és ennek ellenére a verziója még nem érte el az 1.0.0-át. Ezzel szemben más esetekben a verziószám már két számjegyű, mert a bugfix-ek is major szám növekedést eredményeznek. Tehát a verziószámból semmilyen következtetés nem vonható le. Helyette a kiadási megjegyzéseket kell olvasgatni.

Egyéb leírom: (libák és apik) szép és jó dolog a semver, jó lenne, ha mindenki használná is, de nem így van, úgyhogy lényegtelen kérdés, mert per pill. (a következetesség hiánya miatt) az információértéke jó közelítéssel nulla.

(alkalmazások) kit érdekel? Ki tudja megmondani, hogy milyen fő verziójú mondjuk a böngészője a gépén? Elenyésző kisebbség, és még aki tudja is fejből, hogy mondjuk 46-os, az is mit jelent?

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Jó lenne, ha egy 1 milliárdos piacvezető cég termékének (ami történetesen egy jar library) 3.2 és 3.7-es verziója között nem tűnt volna el egy osztályról egy metódus, anélkül, hogy depricated lett volna valaha is... Biztos szerepel a változások listáján, de akkor is elég váratlan volt.

Igazából egy kompatibilitási gráfot kellene rajzolni, mert van amit nem lehet kifejezni szemantikus verziókkal.

Eleve nem kéne keverni a marketingesek és a fejlesztők által használt verziózást. A Hiperszuper 2016 belsős verziója simán lehet 1.23.4 is, azt nem kell a dobozra ráírni. Sőt, ha jön egy patch, akkor az 1.23.4 megváltozik, de a 2016-nak nem muszáj.

Az a baj ezzel, amikor a gyártó maga is keveri a kettőt.

Indítok egy cmd-t, és nem azt mondja, hogy Microsoft Windows 7 build 7601, hanem azt, hogy Microsoft Windows [Version 6.1.7601]. Vagy az Office 2007 könyvtárának az lesz a neve, hogy Office12. A Visual Studio 2008-hoz tartozó runtime lib neve MSVCRT 9.0, nem pedig 2008.

Ez ordas nagy mellébeszélés :)
Röviden: nem csak átlag userek vannak.
Hosszabban: majd ha a vendor deklarálja, hogy nem célja, hogy a nem átlag userek használják a cuccait, akkor lehet arra hivatkozni, hogy a nem átlag userek le vannak szarva. Addig azonban, amíg világuralomra tör egy vendor, addig a nem átlag userek seggét is fényesre kéne nyalni problémáival is kéne törődni.

Mondtam én, hogy csak átlag user van? Pont azzal kampányolok a kettős verziózás mellett, hogy amíg az egyszeri Józsibá' rákeres a google-ben, hogy "office 2016 doesn't work", addig a power userek támaszkodhatnak a tényleges verzióra, használhatja a cmd-t, stb.

Hogy sikerült ebből eljutni oda, hogy a nem-átlag user le van szarva?

A kettős verziózás azt eredményezi, hogy a gugli hatékony használatához mindkét verziószámra rá kell keresni. Amihez ismerni kell mindkettőt... Igazából Józsibá-nak is ismernie kéne, de őt annyira nem hatja meg, ha nem találja meg a megoldást a neten, mert elkönyveli, hogy szarazegészkóceráj-szaravindóz, de a power user ennyivel nem szokta beérni. Ergó a power user lesz az, aki szopik... az igazán májer power userek még azt is számon tartják, hogy a Windows 7 meg a Server 2008 R2 dettó ugyanaz, ergó ha az egyikre talál megoldást, az jó eséllyel a másikon is megoldja majd a baját.

"az igazán májer power userek még azt is számon tartják, hogy a Windows 7 meg a Server 2008 R2 dettó ugyana"
Nem ugyanaz, de vannak olyan komponenseik, amelyek ugyanazok.
Épp ezért fontos a technikai verziószám.
A nem power usernek meg elég az, hogy a legfrissebb stuff van a gépén, ami az adott OS által szállított szoftverbolt managel.
Az okostelefonok elterjedése bizonyította, hogy ez kell az átlagfelhasználónak. Kérdezd meg az átlagfelhasználót, milyen verziója van a Facebook appnak, meg a böngészőnek a telefonján. Nem fogja tudni, mert nem érdekli. Ha meg baja van, beírja a Google-be, hogy "Facebook app android problem foobar" és megpróbál tájékozódni. Leszarja a verziószámot.
Aki meg power user, a technikai verziószámot meg tudja találni, és fel tudja használni, mert elérhető. Még API-ból is, azaz például alkalmazásfejlesztéskor is megcsinálhatod, hogy mondjuk megnézed, milyen verziójú Facebook/Twitter/Chrome/FooBar van telepítve, amivel integrálódnál, és ha túl régi, szólsz a usernek, hogy frissítsen.

"Az okostelefonok elterjedése bizonyította, hogy ez kell az átlagfelhasználónak. Kérdezd meg az átlagfelhasználót, milyen verziója van a Facebook appnak, meg a böngészőnek a telefonján. Nem fogja tudni, mert nem érdekli. Ha meg baja van, beírja a Google-be, hogy "Facebook app android problem foobar" és megpróbál tájékozódni. Leszarja a verziószámot."

Ahol "megpróbál tájékozódni" = "megpróbál aktuális infót találni a rengeteg 1-2-3-több éves, többé-kevésbé kapcsolódó találat között".
Verziószámmal alighanem egyszerűbb lenne.

ezt jegyezzuk mar fel a gelei megint megmagyarazza topikba 'yet another bullshitting' cimszoval...

--
"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)

azt ne mond, hogy nincs igaza...
a telefonomon egyszer nem indítottam shellt, gőzöm nincs, milyen verziójú rajta bármi is.

ahogy szerintem egy kezemen meg tudom számolni, hogy az ötfős családból a többiek összesen hányszor indítottak parancssort az elmúlt 10 évben.

de még én is csak érdekességképpen tudom, hogy az a ~6-7000 körüli szám mit jelenthet a CMD-verziójában.
--
blogom

Fejlesztői és felhasználói szemmel is fontos (szerintem).

Pont néhány napja futottunk bele kollégámmal egy jó kis problémába, mely a verziószámozással történt.

Van egy vállalatirányítási rendszer amihez mi nyújtunk technikai hátteret itt MO.-on. Ennek verziószámozása a következő például: 2015r2n05, 2016r2n02, 2016r4n02

Verziófrissítés lett volna az egyik cégnél. 2015r2n15-ről próbáltunk 2016r2n02-re frissíteni, ám sehogy sem sikerült.

A végén derült ki, hogy a 2015r2n15-ös verzió újabb, mint a 2016r2n02, azaz mi downgrade-t próbáltunk végrehajtani, ami természetesen nem sikerült a rendszernek.

Egyéb, leírom: üzemeltető vagyok és nem érdekel, csak következetes legyen.

Az általunk fejlesztett egyedi vállalatirányítási rendszer most tart az 1.0.481 verziónál.
Céges környezetben, saját fejlesztésű szoftvereknél a verziószám egyetlen feladata, hogy megbizonyosodjunk a legújabb verzió használatáról.

Széleskörűen használt projekteknél fontosabb kérdés, és célszerű a Semantic verziózás.

fontos kerdes (fejleszto vagyok)
fontos kerdes (user vagyok)

--
"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)

major.minor.patch-datum-commithash

pl:
0.4.3-20160504-0ac1b1f

Verzio nekem, a datum a usernek, hogy tudja mikori. A commithash meg a bugreportnal jon jol, hogy melyikbol lett buildelve.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

A release date szerepeljen valahol a doksiban, az a legfontosabb.

--
GPLv3-as hozzászólás.

Userként szeretem, ha a főverzió akkor lép egyet, ha a gui nagy mértékben változik. (fontos, guit használjuk-látjuk)
Userként, ha a gui alig változik, de lesz új feature, akkor mondjuk a főverziót jelölő szám melletti változzon. (nem annyira fontos)
Userként, ha a gui nem változik, csak, mondjuk bugfix, akkor a legkisebb helyiérték lépkedjen. (nem annyira fontos)
Userként néha jó látni a verzióban a dátumot is valahol.

Böngészőknél pont valóban káosz van, de legalább nem fontos tudni, amíg auto update van. Így nem zavaró, mert egyértelműen mindig a "ma elérhető" a verziója az én értelmezésemben.

Üzemeltetőként rendkívül fontos kérdés. Pláne az Oracle világában. A hibák 90%-a verziók közti inkompatibilitásából, funkciók ki, be és átstrukturálásából erednek. Így az üzemeltetés részéről folyamatos kihívás a fejlesztők és a rendszerintegrátorok részére.

Fejlesztőként nagyon fontos. Felhasználóként csak annyira, hogy le tudjam szűkíteni a keresést, ha valami nem jó és rá kell Guglizni.

A verzioszamozas fontos, de a mikentje lenyegtelen. A verzioszam legyen egyedi es ennyi eleg is. A fejeleszto (es remelhetoleg a felhasznalo is) ugyis tudja, hogy hol van a kiadashoz tartozo reszletes leiras. Soha sem szeretem amikor egy ilyen azonositoba informaciot probalnak csomagolni. Vegeredmenyben ugysem lesz megbizhato.

Debian, Ubuntu verziók tetszenek felhasználóként. Pl.: 8.3, 16.04.3 stb. Így már az átlag felhasználók is kapnak egy viszonylag pontos képet. A poweruser meg úgyis követi a changelogot, ha szükséges. Amin most ki vagyok akadva: openSUSE 42.1... Eddig volt valami logika, amivel lehetett datálni valahova azonnal. Most ennek vége.
--
zsebHUP-ot használok!

ouch!

Na most nézem meg ezt a filmet... :-D ()

Még egy utolsó kérdés: Ha az életre, meg a galaxisra, meg minden kérdésre az egyetlen létező tökéletes és rövid válasz a 42, akkor openSUSE-ék, már mindenek felett állnak, hogy ők már előjöttek a 42.1-es megoldással? :-D

BunsenLabs

"Még egy utolsó kérdés: Ha az életre, meg a galaxisra, meg minden kérdésre az egyetlen létező tökéletes és rövid válasz a 42, akkor openSUSE-ék, már mindenek felett állnak, hogy ők már előjöttek a 42.1-es megoldással? :-D"

Mindegy, amíg a kérdés nincs meg! :D
Az pedig nem lett meg; egy szörnyen ostoba katasztrófa miatt meghiúsult tízmillió év fáradozása...

Üdv,
Marci

Ízlése válogatja, szerintem mindegyiknek megvannak az erősségei. Amúgy a könyv tetszik nekem is legjobban.
Megtudhatjuk belőle, mi áll Mr. Prosser kis szőrmekalapok iránti vonzalmának hátterében, viszont nem láthatjuk azokat az arckifejezéseket és nem hallhatjuk akcentusát, mint itt: https://www.youtube.com/watch?v=tTNuldPhP20&list=PLWq3bG2Bl88xvcfTcdwBq…

Üdv,
Marci

viszont nem láthatjuk azokat az arckifejezéseket és nem hallhatjuk akcentusát

Ha elég jó a könyv, akkor pont azokat az arckifejezéseket "látod" és akcentusokat "hallod" belőle. Ha meg nagyon jó a könyv, akkor akár egész más arckifejezést látsz benne te, mint amit látok én.

Pl. amikor olvastam őket, Marvinról mindig valami olyasmi robot jutott eszembe, mint a Beneath a Steel Sky-ban Joey legelső állapota (ezen a képen a bal szélen, a második állapota a középső robot lesz: http://www.giga.de/macnews/wp-content/uploads/2009/10/bass4-rcm781x0.jpg), ahhoz képest a filmbeli Marvin hatalmas csalódás volt (annak ellenére, hogy értem, hogy akár így is kinézhet)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Mindig csodáltam azokat a programokat, amiket a készítési dátum (amit simán lehet módosítani), vagy a neve alapján (szintén) különböztettek meg. A legviccesebb az volt, amikor egy fejlesztő a hálózat közös csatlakoztatott meghajtója ellenére különböző gépekre különböző verziójú "egy-exe-szoftver"-t tett ki az asztalra (nem parancsikont), ugyanazzal a névvel. Legalább garantáltan ne lehessen tudni mi hol miért működik. Természetesen az assembly-nek hogy adott volna valami verziót, azt hiába kérték. Aztán persze kitették a szűrét, csak nem értem hogy még ez után is miért nem változtatott ezen a szokásán más cégnél sem minthogy hallottam róla.

Én nem vagyok gyakorlott és sok ismeretnek még jócskán híján vagyok, de hogy még változtatni sem szeretnének az emberek ezen a habituson és nem értik meg hogy saját életüket teszik nehezebbé, azt végképp fel nem foghatom. Szóval igen, szerintem fontos :)

> garantáltan ne lehessen tudni mi hol miért működik.

https://en.wikipedia.org/wiki/SHA-2

> Szóval igen, szerintem fontos :)

Kevered a verzioszamot es annak mikentjet a kovethetoseggel. Nem kerdes, hogy a kovethetoseg fontos, nade szamit, hogy az most egy egyszeru szam (verzio 1,2,3,4,5..), egy datum (verzio 20160525), vagy esetleg a verziokoveto rendszer (SVN/GIT/akarmi) altal szolgaltatott egyedi szamsor?
Szerintem mindegy amig a felhasznalok tudja, hogy melyik verziot kell hasznalniuk, es hogyan tudnak frissiteni. Sokak szerint a kompatibilitast is bele kell kodolni a verzioba, de szerintem ezt megbizhatoan nem lehet csinalni.

" nade szamit, hogy az most egy egyszeru szam (verzio 1,2,3,4,5..), egy datum (verzio 20160525), vagy esetleg a verziokoveto rendszer (SVN/GIT/akarmi) altal szolgaltatott egyedi szamsor?"
Igen, szamit. Hasznos peldaul, ha a verzioszam tartalmazza a kompatibilitasi informaciot, hogy a csomagkezelo el tudja donteni, hogy frissithetsz-e kompatibilitasi gond nelkul, vagy nem.

Valoban, egy tokeletes vilagban ez tok jo lenne. Gyakorlatban viszont nehez eldonteni, hogy mi fog kompatibilitasi problemat okozni, es a verzioszam nem a legjobb hely ennek az informacionak a tarolasara. A csomagkezelo peldaul inkabb hasznaljon egy leirofajlt erre.

A tapasztalatom az, hogy rossz dolgok tortennek amikor tul sok informaciot akar valaki egy olyan szamban tarolni aminek a legfontosabb tulajdonsaga az, hogy egyedi. Ha van egy egyedi azonositod, arra nagyon konnyu keresni es megtalalni a kiadas pontos reszleteit.