Andrew McIntyre wrote: > > On Sep 20, 2005, at 8:18 PM, Daniel John Debrunner wrote: > >> I would say that if the version of the 10.1 branch is 10.1.1.1 then a >> fix should result in the bug being marked as fixed in '10.1.1.1 >> (unreleased version)'. Ie. correctly represent the version of when the >> bug was fixed. >> >> Once 10.1.2 is released (or maybe a release candidate) then any bugs >> fixed in 10.1 since the last release could *also* be marked fixed in >> '10.1.2 (released version)', not replace the fixin of 10.1.1.1. This >> additional fixin is to link the bugs with the release and helps the >> release notes generation. > > > My only problem with this is that eventually you will end up with scores > of unreleased versions in the bug tracking system. If we're not ever > planning on releasing that version, why bother having a number for it at > all? Why not just bump the version on the branch to 10.1.2.0 now and > start marking all of the bugs fixed in 10.1.2.0, since we've already > agreed that that's the next version we're actually going to officially > release?
Good points, but remember that we (the Derby project) may not be the only group making a release. Anyone, this being open source, can make a version of Derby for their own purposes, e.g. to redistribute within their company. Thus those version numbers can represent a period of time for the branch. > >> Changing history of a bug tracking system is generally a thing to avoid. > > > So is clogging it up with meaningless values for the version numbers. I don't believe they are meaningless. They represent the version of the branch at some point in time which may have been used by someone. > The bigger issue is that we don't really know what that fourth position > means. It doesn't seem to mean bugfix release, since it appears we've > agreed that's what the third value represents. If we're not ever going > to release a version that uses it in a meaningful way, then what is it > doing there? For a branch I would say (using 10.1 as an example) - bump fourth digit at least after every snapshot, release candidate or release - bump third digit for the first candidate of a release 10.1.1.0 Initial release 10.1.1.1 bumped after release 10.1.1.2 bumped after snapshot (of 10.1.1.1) 10.1.1.3 bumped after snapshot (of 10.1.1.2) 10.1.2.0 release candicate one for 10.1.2 10.1.2.1 bumped after rc1 rc1 goes for voting, some issues & fixes made to the branch 10.1.2.1 release candicate two for 10.1.2 10.1.2.2 bumped after rc2 rc2 accepted as official 10.1.2 release, its version is 10.1.2.1 (and similar release candidate version changes could happen on the intiial release, but I matched what is in 10.1 at the moment). Dan.
