Re: Stable branch release manager for Guile

[Rob Browning]

Mikael Djurfeldt <address@hidden> writes:

> 1. You're hereby appointed "stable branch release manager" with
> responsibility for deciding when to make releases, what to put in
> them, and do them.

All right.  Here we go :>

> 2. As you probably already have noticed, we try to follow the
> checklist in guile-core/RELEASE when making releases.  There is
> especially one trap, which probably isn't spelled out clearly
> enough, which you should watch out for when making the dist archive:
> In order to get all .x dependencies properly generated, you need to
> configure the package with --enable-maintainer-mode and *all* other
> configuration options which add files to libguile, such as
> --with-threads.  Furthermore, before typing 'make dist', you
> actually have to do 'make clean' and 'make' in order for the .deps
> directories to get the proper contents.

OK.  Some of this I'd wondered about.  I had to deal with related
issues when patching the Makefile.am's for Debian to incorporate the
libguilereadline/libqthreads versioning issue.  Thanks.

> > If not, is there any possiblilty we could skip 1.4.1, release a new
> > stable 1.4.2 (publically), and shift the development tree to 1.5.X?
> 
> 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.

> 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.
 
> 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 :>

> > 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.  These are the changes to version libguilereadline and
libqthreads with the same major number as libguile.  Previously, guile
wasn't versioning these shared libs at all, which can cause problems.
Specifically that (along with some other issues) is why in Debian I
wasn't able to keep it so that guile 1.3 and guile 1.4 (and programs
that depend on libguile6 and libguile9) could both be installed
simultaneously.  Now that the qthreads/readline versioning's set up
(and I've cleaned up a few other problems of my own wrt the packages),
I may be able to avoid that limitation in the future.

Hoewever, I'm wondering if this isn't only a partial solution.  One
thing messing with g-wrap and guile's shared lib (dynamic-link) system
has pointed out is that we may need to more explicitly address binary
versioning issues.  For example, what happens if you have
libguilereadline.9.so and libguilereadline.12.so installed which are
needed by guile1.4 and guile1.6 and aren't binary compatible.  How
will each guile be able to get the right one at dynamic-link time?
The last proposal I saw suggested putting all the libs into /usr/lib,
so without explicit version handling on the scheme side (say via
(dynamic-link foo version)) or whatever, it seems like you'd be stuck.

If we ever want to have (use-modules (opengl)), etc. then we'll need
to think about this.  If we follow the libtool versioning
recommendations, we could at least check compatibility at runtime
(during the dynamic-link), but we may want/need to do better than
that.

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

-- 
Rob Browning <address@hidden> PGP=E80E0D04F521A094 532B97F5D64E3930