Hello all, Looks like a good versioning strategy for me,
I'm just skeptic about how this will be understood by the user, and what are the real advantages between this and a traditional versioning strategy ? The first advantage I see: It's prevent to increment major version too much if we have small development iteration - having version 20.1 in 2 years for example ;) But in case of long time iteration I don't see the advantage, what are the planned release cycle ? I don't see any date on the roadmap: http://wiki.apache.org/hama/RoadMap Thanks ! On 15 April 2011 04:28, Edward J. Yoon <[email protected]> wrote: > Maybe this is what we should do .. > > ---- > MongoDB uses a fairly simple versioning scheme: even-point releases > are stable, and odd-point releases are development versions. For > example, anything starting with 1.6 is a stable release, such as > 1.6.0, 1.6.1, and 1.6.15. Anything starting with 1.7 is a development > release, such as 1.7.0, 1.7.2, or 1.7.10. Let’s take the 1.6/1.7 > release as a sample case to demonstrate how the versioning timeline > works: > > 1. Developers release 1.6.0. This is a major release and will have an > extensive changelog. Everyone in production is advised to upgrade as > soon as possible. > > 2. After the developers start working on the milestones for 1.8, they > release 1.7.0. This is the new development branch that is fairly > similar to 1.6.0, but probably with an extra feature or two and maybe > some bugs. > > 3. As the developers continue to add features, they will release > 1.7.1, 1.7.2, and so on. > > 4. Any bug fixes or “nonrisky” features will be backported to the 1.6 > branch, and 1.6.1, 1.6.2, and so on, will be released. Developers are > conservative about what is backported; few new features are ever added > to a stable release. Generally, only bug fixes are ported. > > 5. After all of the major milestones have been reached for 1.8.0, > developers will release something like, say, 1.7.5. > > 6. After extensive testing of 1.7.5, usually there are a couple minor > bugs that need to be fixed. Developers fix these bugs and release > 1.7.6. > > 7. Developers repeat step 6 until no new bugs are apparent, and then > 1.7.6 (or whatever the latest release ended up being) is renamed > 1.8.0. That is, the last development release in a series becomes the > new stable release. > > 8. Start over from step 1, incrementing all versions by .2. > > -- > Best Regards, Edward J. Yoon > http://blog.udanax.org > http://twitter.com/eddieyoon > -- *Alois Cochard* http://aloiscochard.blogspot.com http://twitter.com/aloiscochard
