Verziószámozás változtatásra készül a PostgreSQL projekt

Szoftver

Josh Berkus, a PostgreSQL Core Team tagja a minap arról blogolt, hogy a legutóbbi PgSQL fejlesztői találkozójuk óta a projekt azon elmélkedik, hogy változtatniuk kellene a verziószámozáson. Jelenleg így konstruálják a verziószámot: 

        9 . 5 . 3 

   Major1 . Major2 . Minor

Ezt változtatnák meg az alábbira: 

           10 . 2

        Major . Minor

Részletek itt. A kommentekből kiderül, hogy a PgSQL csapat számításba vette pl. a semver.org ajánlásait, de azt nem találta kielégítőnek a problémáira.

( asch v | 2016. 05. 20., p – 11:22 )

Mondjuk azt nem értem, hogy ehhez minek bármin is változtatni? Egyszerűen maradhatna minden ahogy van, csak éppen soha nem emelik a középső számjegyet 0 fölé. Persze az túl egyszerű lenne.

( dotnetlinux | 2016. 05. 20., p – 15:10 )

Komoly problémák ezek :)

Verziószám szabályokat egy-egy új termék létrejöttekor "illik" csinálni. PG kijönne egy új termékkel (not need), akkor azon változtatna...

( persicsb | 2016. 05. 20., p – 16:42 )

Ez nem a technikai verziószám innentől kezdve, hanem csak egy marketing elnevezés.
A technikai verziószám továbbra is a háromkomponensű verziósztringből képzett szám:
"The "sortable" version number available from the server, libpq, and elsewhere would remain the same six digits, zero-filled in the middle. So 10.2 would be 100002.
"

Szóval meg kéne érteni, és el kéne fogadni, hogy van a marketing elnevezés, meg a technikai verziószám, minden esetben. És a technikai verziószámra tökéletes a semver.
Azzal indokolják, hogy nem jó nekik a semver, mert nem csinálnak sosem visszafelé nem kompatibilis változtatást:
"semver major version is for breaking compatibility. This doesn't work for postgres -- I don't think we'd ever allow that."
Az, hogy a postgreSQL nem csinál API breaket sosem, az egy tisztelendő dolog. De ez csak annyit jelent, hogy mindig 1.X.Y.Z a technikai verziójuk, aminek X.Y.Z lehet a marketing verziója.

Persze a mostani dolog sem old meg mindent, az egyik kiinduló gond ugye ez volt:
"as well as ending the need to explain to users that 9.5 to 9.6 is really a major version upgrade requiring downtime."
Akkor mégsem major version upgrade, ha visszafelé kompatibilis, nem? Ha meg nem kompatibilis visszafelé, akkor tessék csak bumpolni a major verziót.

Érthetetlen ez a dolog, a PostgreSQL számomra eddig jó mérnökök csapatának tűnt. Ez a döntés nem arra mutat.

""as well as ending the need to explain to users that 9.5 to 9.6 is really a major version upgrade requiring downtime."
Akkor mégsem major version upgrade, ha visszafelé kompatibilis, nem?"

Ugyanabban a blogpostban: "Historically, we've advanced it because of major milestones in feature development: crash-proofing for 7.0, Windows port for 8.0, and in-core replication for 9.0."

Na és, ez azt jelenti, hogy a verziószámozásuk nem volt szemantikus, nem tartalmazott semmilyen információt a kompatibilitásról, hanem csak egy marketing elnevezés volt.
Persze idővel majd ők is felismerik, hogy a marketing elnevezés, meg a technikai verziózás más téma. De még nem tartanak ott.

Az, hogy kitalál valaki egy verziózási rendszert (semver), az nem jelenti azt, hogy az az egyetlen és jó rendszer.
Azoknál, akiknél nincs kompatibilitási kérdés, azoknál ez teljesen rossz rendszer. pl. az 1.12.x és 1.15.x közt csak annyit látsz, hogy néhány plusz funkció került bele, holott lehet, hogy az sokkal több információt hordozna számodra, ha a verzióban megjelenne, hogy teljesen átalakult az UI és/vagy a fájl formátuma, miközben visszafelé teljesen kompatibilis. Ilyenkor sokkal több információt hordozna az 1.12.x és a 2.2.x, mert látnád, hogy rengeteg újdonság került a rendszerbe és már két újabb kiadás is kijött azóta, így nyugodtan verziót válthatsz rá.

Azzal meg mélységesen nem tudok egyetérteni, ha kétféle verziószámozást is alkalmaznak egy terméknél (ún. technikai, marketing)

"ha a verzióban megjelenne, hogy teljesen átalakult az UI és/vagy a fájl formátuma, miközben visszafelé teljesen kompatibilis."
Az 1.12.0-ban és 1.15.0-ban is benne van, pont ugyanannyira, mint a 12.0 vs 15.0-ban.

" 1.12.x és a 2.2.x, mert látnád, hogy rengeteg újdonság került a rendszerbe és már két újabb kiadás is kijött azóta, így nyugodtan verziót válthatsz rá."
Mivel megváltozott a főverzió, visszafelé nem kompatibilis változás történt, épp ezért nem igaz, hogy nyugodtan verziót válthatsz rá.

"Azzal meg mélységesen nem tudok egyetérteni, ha kétféle verziószámozást is alkalmaznak egy terméknél (ún. technikai, marketing)"
Az egyik arra való, hogy beszéljünk róla (pl. Debian Wheezy, Windows Vista, Fedora Heisenbug), amely főleg a featurehalmazt jelenti a usereknek, míg a technikai verziószám API-ból elérhető, a szoftverek számára segít döntést hozni (pl. egy csomagkezelő számára fontos, hogy ellenőrizni tudja a telepített csomagok vs a deklarált csomagfüggőségek közötti kompatibilitást).

Példa: Nálam mondjuk randomlib 3.5.13 van fent, az egyik szoftver pedig randomlib 2.8.10-et igényel. Válthatok-e rá? A semver egyértelműen megmondja: NEM. Ezt a szabályrendszert be lehet építeni a csomagkezelőbe.
Míg ha valaki nem semvert használ, ott a csomagkarbantartónak kell valahogy kezelnie a kompatibilis/nem kompatibilis listát, hogy mely verzió kompatibilis, mely meg nem. Agyrém.

Akkor fejtsd ki jobban. Azok számára, akik eddig visszafelé kompatibilisek voltak, nem jelenti azt, hogy ezután is mindig azok lesznek. Minden projekt életében előjön az, hogy bizony el kell dobni a kompatibilitást. Épp ezért az a feltétel, hogy "Azoknál, akiknél nincs kompatibilitási kérdés, azoknál ez teljesen rossz rendszer.", nem állja meg a helyét. Az, hogy eddig nem volt kompatibilitási probléma, csak annyit jelent, hogy még nem váltottak főverziót. Szép dolog, de semmi garancia nem lesz rá, hogy nem is fognak soha. És akkor majd néznek, hogy "hú bakker, hogy a francba kéne verziózni inkompatibilis változást, ha eddig a főverzió váltás nem jelenetett ilyet?". A semvert nem véletlenül találták ám ki.

Rendben, megpróbálom.

Ahol jellemzően előfordul visszafelé kompatibilitási kérdés, ott alapvetően egyetértek a semver-féle verziókezeléssel (általában library-k).
Ahol viszont soha nem fordul elő (lehetnek library-k is, de főleg alkalmazások), ott semmi értelmét nem látom, hogy 1.0-tól 1.2578.x-ig menjen a verziószámozás, semmi információt nem hordoz a fő verziószám, holott hordozhatna más szemszögből.
Erre írtam példaként, hogy ilyen esetben az 1.12.x és 1.15.x között annyit tudsz meg, hogy visszafelé kompatibilitási probléma nem történt és pár új funkció került a programba. Ha viszont más megközelítés szerint képeznék a verziószámot, ha pl. teljesen átalakult az UI és/vagy a fájl formátuma megváltozott visszafelé kompatibilis módon, sőt úgy változott, hogy a régi is tudja olvasni az új formátumot, de az újdonságokat nem tudja megjeleníteni, akkor ilyenkor növelnék a fő verziószámot, pl. 1.12.x-ről 2.0.0-ra. Ilyenkor a verziószámból eldönthető, hogy nem akarok az új verzióra frissíteni, mert a dolgozóimat át kellene képeznem az új menü miatt (pl. ribbon menü került a klasszikus helyére), vagy a régi programjaimban bizonyos információk "elvesznek" (nem fognak látszani), mert az új fájlformátumból nem tudja a régi az újdonságokat megjeleníteni.
Illetve, ha úgy döntenék, hogy átlépek az új verzióra, mert a dolgozóimat már átképeztem, illetve mindenhol tudok új programra váltani, akkor a 2.2.x-ből (vagy 2.0.15) tudom azt, hogy kellően stabil az új verzió, nagy problémát vélhetően nem fog okozni az átállás.

"Azzal meg mélységesen nem tudok egyetérteni, ha kétféle verziószámozást is alkalmaznak egy terméknél (ún. technikai, marketing)"

Itt pedig nem arra gondolok, amikor egy könnyen megjegyezhető nevet adnak egy fő verziónak, hanem arra, amikor ténylegesen más verzió SZÁMot kap, pl. 6.2 - 8.1.

Nem írtam, hogy alkalmazásnál ne lehetne értelme.

1. Alkalmazásnál akkor van értelme, ha főként az API-ján keresztül használják.
2. Ha főként nem úgy használják és/vagy az API-ja nagyon stabil, akkor célszerű lehet az API-ját külön verziózni.
3. Ha egy alkalmazás egyszerre több szolgáltatást nyújt, akkor célszerű lehet a szolgáltatásokat külön verziózni.
4. Sok esetben az a célszerűbb, ha nem a szolgáltatásokat verziózzák, hanem a tartalmat (pl. Rest esetén a content negotiation vagy a saját fájl formátumok)

Pl. A LibreOffice, ha jól tudom a 3.3-as verziótól kezdve a legfrissebb 5.1-ig, az ODF 1.2-es verzióját használja a saját fájl formátumaként.

Az ugye megvan, hogy a PostgreSQL is csinált visszafelé nem kompatibilis változtatást, 9.1 és 9.2 (úgymond minor verziók) között is?
https://wiki.postgresql.org/wiki/What%27s_new_in_PostgreSQL_9.2#Backwar…
https://wiki.postgresql.org/wiki/What%27s_new_in_PostgreSQL_9.1#Backwar…

De ez ne zavarjon :)

Lenyegeben semmi. A ketto egyutt major, bamelyik valtozik az major change.

Egyebkent IMHO major jelentes megmarad,
MINOR ill. PATCH nem lesz megkulomboztetheto. (Nem lepne meg, ha az enterprise valtozatok kapnanak egy 3. digitet)

Az uj Major akkor valtozik, ha downtime kell a cluster upgradhez.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Mi a kedvenc,legjobb HA setup postgresql -el 2016 -ban, a legujabb stabil verzioval?

PosrgreSQL -wiki-n tobb HA megoldas van felsorolva, mint egen a csillag.
Melyik alapjan iteljem meg a PostgreSQL -t ? (Teljesitemeny is szamit)

Amit nem lehet megirni assemblyben, azt nem lehet megirni.