Re: [Cppunit-devel] 2. configure.in queries

[Steve M. R. <ste...@vi...>]

On Fri, Jul 06, 2001 at 01:53:55PM +0200, Bastiaan Bakker wrote:

> > Would anyone object to the following two changes to configure.in?
> > 
> > 1. remove AM_DISABLE_STATIC

  [ ... ]
> Let's remove it and see what happens :-)

OK, I'll do so when sourceforge comes back to life.


> > 2. bump the version string to 1.5.6
> > 
> > Rationale: to differentiate CVS cppunit from the last released
> > version.  
> 
> But then how do you differentiate between CVS and the upcoming 1.5.6? 
> Basically we have 2 choices: 
> 1) update the version number immediately before a public release.
> 2) update the version number immediately after a public release.

There is a third option: do both.  That's how you can distinguish
between public releases and CVS.  

 
> 1) is what we (I) do now, and it is also the method described in the
> autoconf/automake docs.

I didn't realise this was discussed in the autoconf/automake docs.
I typically follow a procedure something like that described in libtool's
"README-alpha" (see below) which I now see uses option #3, in fact.

 
> So let's update to version 1.5.6, and work towards a release of it. Then
> immediately update the version 1.5.7 and maybe straight to 1.6.0 if the
> feature set changes to much.
> 
> Does anyone have showstopper issues for a 1.5.6 release? 

I implemented a workaround last night for systems that lack <sstream>,
based on your suggestion of some weeks ago.  I'd like to commit that
before the next release.

Incidentally, I noticed that the generic "INSTALL" file has changed
with autoconf 2.50.  Since the latter is now mandatory, I'll update
the INSTALL in CVS, too.


-Steve




------------ Excerpt from README-alpha in libtool CVS ------------------

================================================================
= Administrivia

* If you incorporate a change from somebody on the net:
  If it is a large change, you must make sure they have signed the
  appropriate paperwork, and be sure to add their name and email
  address to THANKS

* If a change fixes a test, mention the test in the ChangeLog entry.

* If somebody reports a new bug, mention his name in the ChangeLog entry
  and in the test case you write.

* The correct response to most actual bugs is to write a new test case
  which demonstrates the bug.  Then fix the bug, re-run the test suite,
  and check everything in.

* Some files in the libtool package are not owned by libtool.  These
  files should never be edited here.  These files are COPYING, INSTALL,
  config.guess, config.sub, install-sh, mdate-sh, mkinstalldirs,
  texinfo.tex.

* Changes other than bug fixes must be mentioned in NEWS

================================================================
= Test suite

* Use "make check" liberally, on as many platforms as you can.  Use as
  many compilers and linkers you can.


================================================================
= Release procedure

* Fetch new versions of the files that are maintained by the FSF.
  config.guess and config.sub are available via ftp from
  ftp://ftp.gnu.org/gnu/config/

* Update NEWS.

* Update the version number in configure.in.
  (The idea is that every other alpha number will be a net release.
  The repository will always have its own "odd" number so we can easily
  distinguish net and repo versions.)

* Configure, build, and install.

* Commit

* Run `make cvs-dist' which will tag the tree with release-maj-min<alpha>.

* Run `make cvs-diff' which will create a diff file against the previous
  release tag (set OLDVERSION=min.maj<alpha> in the environment beforehand
  if necessary).

* Download a copy of the previous release tarball and generate an
  xdelta with:

    xdelta delta libtool-<prev>.tar.gz libtool-<version>.tar.gz > \
    libtool-<prev>-<version>.tar.xdp.gz'

* Upload release tarball, diff file and xdelta file 
  ftp://melange.gnu.org/~ftp/gnu/libtool and send announcement to
  li...@gn....

* If not an alpha, announcement must also go to inf...@gn..., and an
  upload request be sent to ftp...@gn... requesting files be transferred
  from ftp://alpha.gnu.org/gnu/libtool to ftp://ftp.gnu.org/gnu/libtool.

* Update version number in configure.in to next alpha number.

* Commit.

--------------------------------------------------------------------------

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants