On Tue, Oct 13, 2015 at 6:28 AM, Camm Maguire <[email protected]> wrote:
> So true. I was hoping that debian unstable was an unused 'sandbox' for > such things. Be that as it may, debian package numbers must monotonically > increase lexicographically, and its not immediately clear what policy > would be superior if we want 2.6.13-1 to be the official release. I > could adjust the minor version number in the image, but there is > really no space here for 'prereleases' with customary historical usage. > I've found that testing builds on the debian autobuilder network is > nonetheless crucial in getting a solid release finalized. Suggestions > most welcome. FWIW Maxima version numbers start with 5.nn.0 for the first release on a branch and go from there. Minor changes are committed to the release branch and 5.nn.1, .2, etc are released thereafter; there is no designated final version number, the most stable or most fixed-up version is just the last one on the branch. On master, the version as defined in configure.ac is 5.nnpost and git describe --dirty says it is branch-5_nn-base-g0123456-mm where mm is the number of commits past the release branch. Packages are only prepared for tags on the release branch, so the only way to get a not-pretty-much-a-release version is to build Maxima from Git. Maxima used to have a 5.$(nn - 1).99rc1, rc2, ... numbering system, but that's a mess, and extra work -- you end up releasing the last version twice. I'm lazy so naturally I figured out something with less effort. Also at one point there was a proposal to use odd/even numbers, similar to Linux kernel releases. I don't think that was ever used. That also seems troublesome -- it's not clear to non-developers what is the significance of the numbers. Maybe this provides some useful inspiration, I don't know. best, Robert Dodier _______________________________________________ Gcl-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gcl-devel
