incubator-hama-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Edward J. Yoon" <>
Subject Versioning
Date Fri, 15 Apr 2011 02:28:35 GMT
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

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

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

View raw message