Re: [Gcl-devel] [Maxima-discuss] unable to set up the help system

[Robert Dodier]

On Tue, Oct 13, 2015 at 6:28 AM, Camm Maguire <address@hidden> 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