Re: Stable branch release manager for Guile

[Mikael Djurfeldt]

Rob Browning <address@hidden> writes:

> > We can do that.  Normally, we should probably fork off a new stable
> > branch from the trunk at each major release.  It's important to
> > remember tagging the directory with nice tags at each release.
> 
> Absolutely.  In gnucash we keep the development version as the main
> trunk, but we fork off a branch each time we make a stable release.

Hmm... we probably mean exactly the same thing.

> > Currently, we are following the convention to mark the current CVS
> > version with an odd third number in the version.  But I suppose that
> > that role will now be taken over by the second number.
> > 
> > But if we plan to make interrim releases of the development branch, we
> > might want to add a new convention.  Dirk has suggested to tag the CVS
> > version 1.5.X-pre.
> >
> > I don't know.  Maybe we can wait a little with that and just tag the
> > CVS version 1.5.X...
> 
> Apologies if people already understood me, or are already familiar
> with the Linux kernel scheme, but to clarify, I was proposing that the
> first updated stable release be 1.4.2, and that you immediately switch
> to 1.5.X on the development branch so that each unstable version you
> release as a tarfile (or whatever) after that will be 1.5.1, 1.5.2,
> 1.5.3, etc.  Then, when you're ready for a new stable release, you
> make a CVS branch and release 1.6.1, and unstable development work
> begins on the new unstable series 1.7.1, 1.7.1, etc.  In this scheme
> everyone knows they've got an unstable version if the middle number is
> odd.

Exactly.  Except that we're probably used to starting the count at
zero in the third digit.  (We're actually used to omitting the third
digit when it "is" zero, but maybe it would be more consistent to
spell it out.)

> > Are you well versed with CVS?  Can you do these things yourself?  Can
> > we trust you?  8-)
> 
> Answers in order: (1) fairly well; (2) yes, though I tend to ask when
> uncertain so I'm usually unlikely to do anything really stooopid on a
> regular basis; and (3) if you're running any Debian machines, then you
> already do :>

Good.  Then please feel free to do it!  :-)

> > > Oh, and I can also add those patches to version libqthreads and
> > > libguilereadline that I've got pending.
> > 
> > What are those?  Is it something we need to add in the trunk as well?
> 
> Probably.  [...]

Interesting.  I think you should start a discussion about this on the
guile-devel list.  Hopefully we can arrive at a proposal for how to do
versioning as a result of that discussion.

A further complication is that many "Guile modules", such as libgoops5
or libguilegtk, for example, are compiled differently depending on
which Guile they are compiled "against".  So, the versioning of a
Guile dynamic linkable library should also reflect the *libguile*
version number!

> Anyway, I'm glad to be here.  Hope I can help.

We are very happy that you want to do this.  Thanks!