On Friday 22 September 2006 17:40, Jon Keating wrote: > Please don't bump up the version number before having a reason. RC1 was > released as 1.3.2, so RC2 should be as well until we get the final > release. At least that way we are consistent. I'd like to have some > final rules about version numbers decided so we can make them consistent > for all releases, and maybe something for CVS releases.
For some final rules my suggestions are: The "old linux kernel versioning" scheme: - Make the version in svn 1.3.3 - Release some (hopefully not that many) release candidates. - When we are ready for a release, bump the version to 1.3.4, tag it in svn, make the tarball and then update the version in trunk to 1.3.5. - Develop new features/fix old bugs. - Back to "Release some RCs" The "it's version A until B is ready" scheme: - Make the version in svn 1.3.2 - Release some more RCs - When the release is ready, bump the version to 1.3.3, tag it in svn and make the tarball (for this release this would have to be 1.3.4 since 1.3.4-rc1 is already out, but in theory it would be 1.3.3). - Develop some more. - Release some RCs - Make the 1.3.4 release, and so on Currently I guess we use some kind of combination where the second scheme is used, but at each version bump a version is skipped. Personally I prefer the pure second variant. I don't think it helps that much to have a separate development version. If a bug is reported against a development version, knowing that it's version 1.3.3 or 1.3.5 doesn't help much. It could be any of the 400 or so revision that has been committed during the 1.3.3 timeframe. And hopefully, people running the development version knows that it is in fact the development version, so it's of no help for them either. // Erik -- The day Microsoft makes something that doesn't suck is probably the day they start making vacuum cleaners. -- Ernst Jan Plugge Erik Johansson http://ejohansson.se
pgp0sToYq5WJC.pgp
Description: PGP signature
