[Alg] Version numbering

[Robtimus]

Just curious:
Hoe nummeren jullie je versies? Begin je meteen bij 1.0, of haal je die grens soms niet eens?

Ikzelf begin tegenwoordig altijd bij 0.1. Omdat ik nooit iets als stable beschouw heb ik de 1.0 ook nauwelijks bereikt.
Ik heb slechts 1 iets met versie 1.0, maar dat begon ook op 1.0. Staat nu trouwens wel op een stabele 2.0.

[MisterData]

Voor normale projecten gebruik ik een versienummer zoals 1.3.0-devel of 2.2.0-stable oid.... meestal begin ik met 0.1.0-devel ofzo. Dat laatste is puur om aan te geven hoe stabiel het zootje op dit moment is Meestal als er een functie is toegevoegd (dus echt een grote functie) dan gaat het tweede nummertje omhoog. Anders het 3e

[Verwijderd]

De algemene benummering is volgens mij, en iemand moet me maar verbeteren als ik het niet goed heb

mayor_release.minor_release.buildnummer

En dan krijg je dus iets als 1.1.10 bijv. Voor versie 1, met eenmaal een minor change, en 10 x gebuild.

[.oisyn]

Even voordat de topic een opsomtopic wordt:
Som niet alleen op, maar geef ook beweegredenen e.d. Onderbouw je posts dus

Ik gebruik vrijwel nooit versionning, maar dingen komen ook nooit ver genoeg om het te releasen (of ik wil ze gewoon niet eens releasen). Maar als ik het doe begin ik altijd bij 0.1b

Bugfixes gaan in de revision number zitten, dus 0.11b, 0.12b, etc. Bij grotere veranderigen wordt de minor opgehoogd, dus 0.2b, 0.3b. En als ik iets compleet overnieuw maak dan komt er een major versie bij. Maar dat is nadat er een 1.0 is gekomen, die ik compleet genoeg vind om te releasen

[ Voor 62% gewijzigd door .oisyn op 29-10-2003 18:52 ]

[curry684]

Ik gebruik versienummers gewoon zoals ze bedoeld zijn (in commerciele projecten that is), met de 4 cijfers in volgorde:
• Major release. Full of almost-full rewrites.
• Minor release. Nieuwe features.
• Intermediate. Bugfixes, interne releases.
• Buildnumber. Opgehoogd bij release builds (vaak wekelijks om een nieuwe 'testversie' te markeren).

Dit is zoals je het hoort te doen volgens de heersende meningen ter wereld

[mbravenboer]

Dit is wel een aardig verhaal: APR's Version Numbering.

Dit schema wordt bijvoorbeeld gebruikt door Subversion. Subversion zit ook al heel lang op dezelfde major. De laatste versie is 0.32. Rond de 0.9 is het misschien wat verwarrend om zo door te tellen, maar dit schema vind ik toch wel erg handig.

Al m'n eigen software zit nog op 0.x in ieder geval .

[Nephilim]

Charles Miller heeft hier enkele maanden geleden nog over geblogged: Version Numbers and You. Hij heeft wel een interessant punt vind ik.

[justmental]

Voor eigen hobbywerk kijk ik alleen naar timestamps, in professionele omgeving werk ik met versienummers voor individuele objecten welke door een versioning tool (pvcs) worden uitgedeeld.
Deze begint met 1.0 en hoogt op naar 1.1 etc.
Bij branches gaat hij door naar 1.x.1.0, 1.x.1.1 etc.

Releases gaan van 1 naar 2 etc en worden via een label ook bij de individuele objecten geadministreerd.
Op de releases kunnen patch sets aangebracht worden welke release.volgnummer meekrijgen.

Waar ik zelf vaak ook nog naar streef is het zichtbaar kunnen maken van versies van objecten op runtime niveau, dit omdat in de huidige complexe architecturen het steeds lastiger wordt om te achterhalen of in elke omgeving wel de juiste versies van objecten gebruikt wordt.

[Scyth]

Ik doe gewoon net zoals nullsoft; ik bedenk gewoon een nummer, als ie maar iedere keer hoger is

[Verwijderd]

offtopic:
Ik begin altijd bij 3.1 totdat het compiled dan wordt het 3.11. Zodra ik denk dat ik klanten mee voor de gek kan houden dat het nuttig is krijgt het versienummer 95. Vervolgens nummer ik door via 98, 2000 en 2003 (beetje willekeurig ophogen dus). Dat is uiteraard nog allemaal in de betafase. Planning is dat ik op 4000 zit als het eindelijk af is.

dus....

Ik nummer zelf niet echt serieus door. Zolang het beta is geef ik het om de zoveel tijd een nieuw nummertje tussen de 0.00 en de 1.00. Het komt erop neer dat ik zo'n beetje schat hoever ik ben. Bij 1.0 is het in principe af. Als ik daarna veranderingen maak dan kijk ik achteraf hoeveel er veranderd is om te bepalen of het 1.x of 2.0 wordt. Niet echt een gestructureerd systeem maar m'n projecten zijn zo klein dat dat niet echt nodig is (vind ik). Versies houden me pas bezig als ik iets release of verkoop op gewoon online zet... niet zolang ik aan het coden ben...

my 2 cents

[Verwijderd]

mbravenboer schreef op 29 October 2003 @ 19:19:
Dit is wel een aardig verhaal: APR's Version Numbering.

(knip)

Al m'n eigen software zit nog op 0.x in ieder geval .

It is important to note that a library that has not reached 1.0.0 is not subject to the guidelines described in this document. Before a 1.0 release (version 0.x.y), the API can and will be changing freely, without regard to the restrictions detailed below.

Misschien moet je toch eens voorbij de 1.0.0 martin, aangezien het nut van het APR schema dan pas echt boven water komt Maar dat inderdaad wel een mooi systeem. Ik denk dat ik dat voortaan maar ga hanteren. Het hele compatibility verhaal heeft natuurlijk pas nut als je een heleboel libs maakt die mekaar gebruiken maargoed, misschien overkomt me dat ooit nog

[mbravenboer]

fladder: Misschien moet je toch eens voorbij de 1.0.0 martin, aangezien het nut van het APR schema dan pas echt boven water komt

Hehe . Veel projecten gebruiken die 0.x in feite als een disclaimer. Zolang je maar onder 0.x zit heeft dan zogenaamd niemand het recht om zich over grove aanpassingen of problemen op te winden. Ik besef idd dat ik me daar zelf ook aan schuldig maak .

[Verwijderd]

curry684 schreef op 29 October 2003 @ 19:06:
Ik gebruik versienummers gewoon zoals ze bedoeld zijn (in commerciele projecten that is), met de 4 cijfers in volgorde:
• Major release. Full of almost-full rewrites.
• Minor release. Nieuwe features.
• Intermediate. Bugfixes, interne releases.
• Buildnumber. Opgehoogd bij release builds (vaak wekelijks om een nieuwe 'testversie' te markeren).

Dit is zoals je het hoort te doen volgens de heersende meningen ter wereld

Waarbij versie nummering voor web applicaties welke niet gecompiled worden in principe geen buildnumber behoeven.

[mbravenboer]

Gordijnstok: Waarbij versie nummering voor web applicaties welke niet gecompiled worden in principe geen buildnumber behoeven.

Dat zou echter wel een revisie nummer kunnen gebruiken van een versie beheer systeem. Zo weet je altijd precies welke revisie ergens gebruikt is. Naast de versie nummers gebruiken wij ook de revisie nummers. De versies leggen in feite slechts een abstractie over die revisies heen.

[Verwijderd]

Maar dan zou je, afgaand op curry's lijst, dit toch beter een intermediate release kunnen geven? Er is immers iets veranderd aan de code. Dat hoeft met een nieuwe build niet zo te zijn.

[ Voor 33% gewijzigd door Verwijderd op 29-10-2003 22:05 ]

[mbravenboer]

Gordijnstok: Maar dan zou je, afgaand op curry's lijst, dit toch beter een intermediate release kunnen geven?

Zo zou je het wel kunnen zien ja. Over het algemeen gaan zelfs intermediate releases wel over een aantal commits. Elke commit zorgt voor een nieuwe revisie. We maken op de UU elke dag distributies van onze software en daar zit meestal een paar revisies verschil tussen.

[.oisyn]

Verwijderd schreef op 29 oktober 2003 @ 21:53:
[...]


Waarbij versie nummering voor web applicaties welke niet gecompiled worden in principe geen buildnumber behoeven.

waarom niet? Dat je niet daadwerkelijk 'compiled' wil natuurlijk niet zeggen dat dat achterste nummer niet bestaat. Je fixt een aantal bugs, verhoogt het build nummer, gooit dat online, en als die stable blijkt dan verhoog je de revision

[mbravenboer]

.oisyn: Je fixt een aantal bugs, ..., gooit dat online, en als die stable blijkt dan verhoog je de revision

De term revisie wordt tegenwoordig vaak gebruikt voor de sources in een versie beheer systeem op een bepaald moment in de ontwikkeling van die software. Elke commit zorgt voor een nieuwe revisie. Alleen het fixen van bugs zorgt dus al voor nieuwe revisies zodra je die commit. Beetje verwarrend dus, want waar jij natuurlijk op doelt is een aanpassing van het patch level. 1.7.2 naar 1.7.3 bijvoorbeeld.

[OkkE]

Ik heb eigenlijk alleen nog maar een (simpel) CMS systeem gemaakt, dit was 1.0.0 toen het voor het eerst aan een klant werd verkocht. Toen heb ik een nieuwe optie toegevoegd; werd het 1.1.0, en later heb ik nog een nieuwe optie toegevoegd; werd het 1.2.0 waarna ik nu net een bug gefixt heb en het 1.2.1 geworden is...

[El_Quedro]

Ik gebruik vooral Visual Studio.Net, en die veranderd automatisch de buildnumbering.
voor de rest begin ik altijd bij versie 0.1 etc etc.
En als ik vind dat ie hoger mag dan gaat ie omhoog

[whoami]

El_Quedro schreef op 30 oktober 2003 @ 16:39:
Ik gebruik vooral Visual Studio.Net, en die veranderd automatisch de buildnumbering.

Niet noodzakelijk.
Als je de AssemblyAttribute zelf specifieert ipv de default

code:

1.0.*

Dan kan je dus zelf je versie-nummer bepalen.


Zolang een exe/dll/whatever backwards-compatible is, zou ik niets veranderen aan de major of minor versie-nr's.

[Eelis]

.

[ Voor 99% gewijzigd door Eelis op 18-02-2015 20:09 ]

[whoami]

Die uitleg die curry geeft, wordt idd wel meestal gebruikt hoor.

[.oisyn]

Eelis schreef op 30 oktober 2003 @ 17:37:
(overigens valt over die vermeende "heersende mening" aan dit topic te zien nog wel te discussieren )

ik denk dat dat meer te maken heeft met het feit dat de GoT community niet de globale programmeurs-meningen representeert Hier zitten relatief veel opensource hippies, terwijl ik denk dat de werkelijke verhouding tussen opensource mensen en commerciele devvers veel meer in het voordeel van de commercielen ligt.

[Tomatoman]

Ook ik nummer volgens de vermeende heersende mening van curry . Het grote voordeel daarvan is dat het buildnummer door de ontwikkelomgeving automatisch wordt opgehoogd bij iedere build. Daardoor kun je versienummers krijgen zoals 1.0.0.58 en volgens mij is daar niets mis mee. Waarom zouden versienummers elkaar altijd moeten opvolgen? Op 1.0.0.58 mag van mij best versie 1.0.0.73 volgen, terwijl de tussenliggende nummers nooit worden uitgebracht.

In mijn software geef ik het versienummer dan als volgt aan in een About-scherm:
Version 1.0 (build 0.73)

[muba]

tomatoman schreef op 30 oktober 2003 @ 20:16:
Waarom zouden versienummers elkaar altijd moeten opvolgen? Op 1.0.0.58 mag van mij best versie 1.0.0.73 volgen, terwijl de tussenliggende nummers nooit worden uitgebracht.

<cut> laat maar, ik lees helemaal niet goed...

Nee inderdaad, je hebt gelijk. Maar het is voor jezelf misschien wel handig om wel ooit de versies 1.0.0.59...72 te maken, zodat het niet een random nummering is maar dat er wel een systeem achter zit. Zoals je al zegt, je hoeft ze niet per se uit te brengen.

[ Voor 54% gewijzigd door muba op 30-10-2003 21:34 ]

[whoami]

MUBA schreef op 30 oktober 2003 @ 21:32:
[...]


Omdat ik toch mag hopen dat de nieuwste versie (ongeacht of het versienummer nou hoger of lager ligt dan het vorige nummer) van je programma meer/betere functionaliteit bevat dan de vorige versie(s).

Dat wil tomatoman toch helemaal niet zeggen?
Als je een nieuwe versie uitbrengt, dan heeft die versie zowiezo een hoger versie-nr (niet lager natuurlijk).
Wat tomatoman wil zeggen is dat die versie-nrs toch niet op elkaar hoeven te volgen, dat er dus gaten mogen in zitten.
Dat je bv. nu versie 1.0.0.3 uitbrengt, en volgende maand bv 1.0.0.5, en dat 1.0.0.4 niet uitgebracht wordt.

[muba]

whoami schreef op 30 oktober 2003 @ 21:34:
[...]

Dat wil tomatoman toch helemaal niet zeggen?

Nee ik heb mn bericht ook al veranderd. Ik had het eerst helemaal verkeerd gelezen/begrepen, maar toen ik het goed las ontdekte ik dat ik het met hem eens was