Bryan Stearns wrote: > Every project I've worked on works the old way: intermediate builds have > a number based on the previous major release, with something incremental > added to it. The only exceptions to this are release-candidate builds
I agree with you, although there are some exceptions in other projects as well. pje actually mentioned something like this on IRC as a suggestion: 0.7dev-m1, 0.7dev-m1 etc. (I think). I don't know how well that would work with .rpm, .deb and other installers. > Heikki Toivonen wrote: >> * Doing a bug fix release of a milestone/release would need to add >> fourth group of numbers, which seems excessive. For example, if we'd >> need a bug fix of 0.6 release, it would have to be 0.6.0.1 to >> distinguish from 0.6.01 milestone on the trunk (and even then there >> might be confusion because of the leading zero). >> > I don't see how the confusing forward-numbering scheme affects this. How > does it solve this problem? We can release 0.6.1, 0.7.1, etc. bug fix releases, and these won't be confused (well, are less likely to be confused) with 0.7.m1, 0.8.m1 etc. >> * It's hard to talk about a milestone with these major, minor and micro >> numbers. The informal way to talk about the milestones has been to say >> m<some number>, which means the the <some number> micro revision in the >> current release cycle. So currently m8 would mean 0.5.08. But this is >> informal, and changes meaning once we switch focus to the next release. >> > Again, the forward-numbering idea still has us talking using major, > minor, and micro numbers. How does it solve this problem? No, we would be talking about m<number>, or if we wanted to disambiguate between a milestone in this and next release cycle we can do so using the full number. >> * Some people would like to use the Bugzilla version field to mark the >> version of Chandler in which the bug was found. This is clear enough >> with a release, but unclear with the current numbering when working >> towards a release. Should the version currently be 0.5 (the previous >> release) or 0.6 (the release we are working towards)? >> > The bugzilla "build identifier" field should be used to record the > specific build where the bug was found. The version number field is too > limited to be useful, and the guided bug-entry page doesn't even ask for > it separately anyway... further, I again don't see how numbering forward > helps in this case: reporters need to record the specific build in which > they found the bug no matter what nomenclature we use. In my opinion the version number field should only be used with bugs that are detected with actual official releases. Generally I ignore that field completely, as I don't think it adds any value. I can find the information it is trying to provide using queries which work IMO better for this. However, the guided bug entry form actually does ask for the full build identifier available in Help > About Chandler dialog. It includes the full milestone AND Subversion revision number. -- Heikki Toivonen
signature.asc
Description: OpenPGP digital signature
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
