Release management

[o_f_course]

Ik ben benieuwd of er standaarden zijn voor release management. En dan denk ik aan:
- nummering van releases
- wanneer noem je iets een minor release, wanneer een major, wanneer een update etc.

Voor alle duidelijkheid, ik gebruik nu Visual Source Safe als Source Code Control applicatie, en er is conversie programmatuur om de applicatie van de ene versie naar de andere te krijgen.
We hebben zelf een release nummer ontworpen, en dat werkt aardig.
Alleen zou het fijn zijn als we naar een bepaalde 'standaard' zouden kunnen verwijzen.

Ik heb wel eens op een uni geinformeerd (paar jaar geleden), maar daar deden ze niets aan onderwijs daarover.

Iemand leesvoer tips?

[muppet99]

*wij eisen normale reacties van users. laat het modereren aan de moderators over.*

Namelijk als ik zoek op standaarden release management vind ik al genoeg leesvoer voor een jaar.

[ Voor 27% gewijzigd door MueR op 23-02-2011 22:00 ]

[o_f_course]

Ik had m'n laatste sub-vraagje beter niet kunnen stellen denk ik, of anders moeten formuleren.

Ja, er is tooling genoeg te vinden op internet om aan versiebeheer van je code etc te doen.
Er is ook genoeg tooling te vinden om aan release management te doen van je software.
En ITIL beschrijft wat je moet documenteren en hoe.

Maar ik ben nog geen beslisboom tegengekomen om te bepalen wanneer je beslist om een major release te doen, of wanneer een sub release. Klanten klagen altijd steen en been dat we teveel in een sub release doen, en vallen over de versie nummertjes die maar oplopen (01,02,03,04,,,,10) terwijl Microsoft een soort obfusicator heeft gehanteerd in z'n versie nummering lijkt het wel...

Is er een standaard beslisboom voor release management?
Is er een standaard voor versie nummering?

Ik geloof best dat ik er langs kijk, de verkeerde termen hanteer of wat dan ook.

[TGEN]

Zolang je versienummering maar consistent is boeit het toch totaal niet wat je gebruikt? Klanten die klagen dat een nummertje zo vaak verandert snappen niet dat software een dynamisch product is, en niet iets simpels zoals een vork.

[YopY]

Een versienummer moet in eerste instantie iets interns zijn (of, in het geval van een API, een hint voor externe gebruikers), als mensen er over gaan klagen moet je óf dat aan ze uit gaan leggen, óf het een volledig developer-georiënteerd iets maken door een changelog (gekoppeld aan een issue tracker dmv issue nummers) bij elke release bij te voegen, óf gewoon geen versienummers gebruiken.

Als klanten klagen dat jullie teveel in een subrelease doen - misschien is dat waar? Maar dat ligt maar net aan jullie releases, het product, en aan backwards compatibility als het gaat om een product waar dat relevant is bij jullie klanten.

Wat we zelf doen is gewoon een major / minor / micro versie (1.0.0). Micro wordt opgehoogd bij bugfix releases, minor wordt opgehoogd bij nieuwe features, en major bij volledige rewrites. Project waar we vooral veel / vaak releases voor doen (een setje templates tbv HTML uitvoer) zat op 1.8.18, zit nu op 1.9...4?, en zal dus binnenkort naar 1.10.0 gaan. Niks mis mee, op zich, zolang het maar consistent is.

Wat je (mijns insziens) niet moet doen is versienummers snel gaan ophogen zodat jullie snel kunnen zeggen dat jullie al op versie 11 van de software zitten (oid).

[o_f_course]

De nummering die we nu hanteren is build,oplevering,testversie?,fixversie?
Zoiets als bv 3.5.1.0, dan weet je dat in die versie fixes op 3.5.0.0 worden intern getest.
Wordt het goed bevonden, wordt er een 3.6.0.0 aangemaakt.
Wordt deze versie afgekeurt (zijn er nieuwe fixes nodig) dan wordt een 3.5.1.1 aangemaakt, die gepropageert wordt naar een 3.5.2.0 tbv interne tests.
Als dat goed wordt bevonden wordt hier (letterlijk) een kopie getrokken naar 3.6.0.0, en die kan naar een klant.

Al deze versie zijn zichtbaar als projecten in VSS.

We hebben een cyclus gehad van ruim een jaar om van bv versie 2 naar 3 te komen. we zijn naar kleinere sub releases gegaan om sneller te kunnen schakelen naar de klant. Dat betekende echter dat bv in 3.7.0.0 een hele nieuwe module erbij kwam, in 3.8.0.0 ook weer een andere module + fixes op 3.7.0.0. We zitten ondertussen van 3.0.0.0 naar versie 3.10.0.0 gegaan, binnen een jaar. Ondertussen is planning voor versie 4 begonnen.

Als ik jullie zo hoor, geen echte opmerkingen, alleen om goed in de gaten te houden wat je in een (sub) release doet.

[djc]

Semantic Versioning is interessant om eens naar te kijken.

[TGEN]

YopY schreef op woensdag 23 februari 2011 @ 15:38:
Wat je (mijns insziens) niet moet doen is versienummers snel gaan ophogen zodat jullie snel kunnen zeggen dat jullie al op versie 11 van de software zitten (oid).

*kuch* Google Chrome *kuch*

[YopY]

TGEN schreef op woensdag 23 februari 2011 @ 17:38:
[...]

*kuch* Google Chrome *kuch*

*kuch* Firefox ook na 4 *kuch* . Regelmatige releases niks mis mee, maar het lijkt toch stiekem op een tweede versienummeroorlog (meen me te herinneren dat dit eerder ook al zo ging, was dat niet met Opera oid?)

iig, ot.

[o_f_course]

djc schreef op woensdag 23 februari 2011 @ 17:36:
Semantic Versioning is interessant om eens naar te kijken.

Hartelijk dank!