Come funzionano i primi numeri di versione per i nuovi prodotti?

Dipende davvero dal progetto; alcuni progetti non rilasciano nemmeno una versione 1.0.

The developers of MAME do not intend to release a version 1.0 of their emulator program. The argument is that it will never be truly "finished" because there will always be more arcade games. Version 0.99 was simply followed by version 0.100 (minor version 100 > 99). In a similar fashion Xfire 1.99 was followed by 1.100. After 6 years of development, eMule has not even reached version 0.50 yet. ^{Software versioning at Wikipedia}

Un metodo popolare di versioni di numerazione (che ho iniziato a utilizzare) è Versioning semantico .

Under this scheme, version numbers and the way they change convey meaning about the underlying code and what has been modified from one version to the next.

Alcune citazioni per darti più idee su come funziona e / o rispondere ad alcune delle tue domande:

How do I know when to release 1.0.0?

If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you're worrying a lot about backwards compatibility, you should probably already be 1.0.0.

Doesn't this discourage rapid development and fast iteration?

Major version zero is all about rapid development. If you're changing the API every day you should either still be in version 0.x.x or on a separate development branch working on the next major version.

If even the tiniest backwards incompatible changes to the public API require a major version bump, won't I end up at version 42.0.0 very rapidly?

This is a question of responsible development and foresight. Incompatible changes should not be introduced lightly to software that has a lot of dependent code. The cost that must be incurred to upgrade can be significant. Having to bump major versions to release incompatible changes means you'll think through the impact of your changes, and evaluate the cost/benefit ratio involved.

Ci sono anche regole su come specificare "alpha", "beta", ecc. Consulta i dettagli sul link .

[Modifica] Un altro interessante schema di numerazione delle versioni è quello utilizzato da MongoDB :

MongoDB uses the odd-numbered versions for development releases.

There are 3 numbers in a MongoDB version: A.B.C

• A is the major version. This will rarely change and signify very large changes
• B is the release number. This will include many changes including features and things that possible break backwards compatibility. Even Bs will be stable branches, and odd Bs will be development.
• C is the revision number and will be used for bugs and security issues.

For example:

• 1.0.0 : first GA release
• 1.0.x : bug fixes to 1.0.x - highly recommended to upgrade, very little risk
• 1.1.x : development release. this will include new features that are not fully finished, and works in progress. Some things may be different than 1.0
• 1.2.x : second GA release. this will be the culmination of the 1.1.x release.

Non penso che ci sia uno "standard" in quanto tale.

C'è una convenzione per i Candidati di rilascio che di solito è "[versione] RC 1" ecc. a seconda di quante versioni pensi che potresti rilasciare.

Se stai pubblicando una versione molto anticipata del tuo prodotto, una che non è completa, allora potresti voler utilizzare la versione "0". In questo modo puoi incrementare la versione nel tempo quando completi il tuo set di funzionalità.

Io userei "Alpha" e "Beta" come Release Candidate - per versioni a tempo limitato per indicare che pensi di essere vicino a rilasciare la versione completa.

C'è una pagina di Wikipedia su Versioning del software . Per la condivisione delle versioni precedenti alla 1.0, la convenzione utilizzata da Apple e altri funziona bene: major.minor.maintSrev dove S è l'indicatore di fase per le versioni preliminari: d = sviluppo, a = alpha, b = beta, rc = release candidate. Quindi la tua prima versione interna potrebbe essere 1.0.0d1.

Per le revisioni completamente interne, il timestamp è sufficiente.

Ogni sviluppatore per la maggior parte decide quale standard saranno utilizzati. In generale, anche se i numeri a sinistra del punto decimale indicano revisioni di grandi dimensioni che potrebbero essere molto evidenti per l'utente medio (ad esempio funzionalità o modifiche dell'interfaccia, ecc.). Sul lato destro del punto decimale questo sarebbe un cambiamento / modifica / addizione che non ha modificato la funzionalità e il design in generale, ma ha modificato qualcosa sul programma stesso (ad esempio, rende più veloce una funzione mentre continua a fare la stessa cosa o fissa un problema di sicurezza). Quindi, se aggiungi ulteriori punti decimali, i numeri a destra di questi indicheranno modifiche sempre più piccole e più piccole (cioè correzioni di bug minori / problemi di sicurezza e simili).

Come altri hanno già detto, non sembra esserci uno standard esatto. La nostra organizzazione utilizza la seguente notazione:

Versione 1.0 --- > 2.0 (Una novità importante / migliorata aggiunta al prodotto)

Versione 1.0 --- > 1.1 (Una funzionalità nuova / migliorata di livello medio aggiunta al prodotto)

Versione 1.0 --- > 1.001 (Bugfixes)

La pietra miliare della "versione 1.0" è molto importante per gli utenti esperti di computer, in quanto implica che il programma sia fatto e funzioni come previsto. Qualunque cosa nella versione "0.something" implica che i programmatori pensino che il programma sia non fatto ancora.

È possibile mantenere i numeri di versione "0.1", "0.2" ... per i principali risultati della funzionalità e quindi suddividerli con un numero di build che spesso è una data e un timestamp sufficientemente definiti.