Stable branch release manager for Guile

[Mikael Djurfeldt]

Rob Browning <address@hidden> writes:

> Mikael Djurfeldt <address@hidden> writes:
> 
> > That would be awesome!
> > 
> > So, you could even imagine being the "stable branch release manager"?
> 
> Absolutely.  I'd be happy to give it a try.  How would we get started?
> i.e. I'm ready to start, what would the mechanics be?

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.

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.

3. Please send your lsh key to address@hidden in order to get
   write access to the repository.  I'll immediately put you on the
   low-traffic:ed internal Guile developers' list
   address@hidden

> OK, how can we resolve the version numbering issue.  If everyone else
> would be happy with the Linux kernel version numbering scheme, that
> sounds good to me

We are happy.

> I don't know how important keeping the upstream version at 1.4.1 is.
> Has it been deployed anywhere?

Nope.

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

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

Are you well versed with CVS?  Can you do these things yourself?  Can
we trust you?  8-)

> 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?

Best regards,
Mikael