cppunit-devel

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

[Bastiaan B. <bas...@li...>]

> -----Oorspronkelijk bericht-----
> Van: Steve M. Robbins [mailto:ste...@vi...]
> Verzonden: Friday, July 06, 2001 3:54 AM
> Aan: CppUnit Development
> Onderwerp: [Cppunit-devel] 2. configure.in queries
> 
> 
> Would anyone object to the following two changes to configure.in?
> 
> 1. remove AM_DISABLE_STATIC
> 
> Rationale: libtool-based packages typically build both shared and
> static libs by default (configure has --disable-static &
> --disable-shared flags for the installer to customize to her taste).
> The principle of "least surprise" dictates that we stick to that
> unless there is a compelling reason for NOT building static
> libcppunit.a.  Is there such a reason?
> 

Not that I know of. Let's remove it and see what happens :-)

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

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

However 2) makes more sense when your project has a main branch for
development and release branches for bug fixes. So far we have not needed to
branch yet, but when we do need to we'll have to adopt this approach anyway.
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? 

Bastiaan


> 
> 
> -Steve
> 
> 
> 
> -- 
> 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
> 
> 
> _______________________________________________
> Cppunit-devel mailing list
> Cpp...@li...
> http://lists.sourceforge.net/lists/listinfo/cppunit-devel
> 

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

[Townsend, G. <gto...@sh...>]

FWIW, I absolutely agree. So much as changed, might as well get something
that will stay fairly stable for some time before the next release.
Especially if it's just a matter of a few days or maybe two weeks.

Guy

> I'd like it if we could to the directory reorganization in the include
> before the 1.5.6. That way we would have something somewhat stable.
> 
> User would already have to do many change to upgrade to 
> 1.5.5. We might as well, get all the "big" change done.

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

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

[Baptiste L. <bl...@cl...>]

>
> Does anyone have showstopper issues for a 1.5.6 release?
>

I'd like it if we could to the directory reorganization in the include
before the 1.5.6. That way we would have something somewhat stable.

User would already have to do many change to upgrade to 1.5.5. We might as
well, get all the "big" change done.

Baptiste.

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

[Baptiste L. <bl...@cl...>]

> Does anyone have showstopper issues for a 1.5.6 release?

Hmm, I still have some clean up to do on the VC++ side.

- A CPPUNIT_TEST_EXPECT_EXCEPTION macro in the work
- can wait but it would be nice to enable the named test suite registration
in this release.

I also like to get done with the test plug in feature (probably this
week-end if I found the time).

Baptiste.
---
Baptiste Lepilleur <gai...@fr...>   http://gaiacrtn.free.fr/index.html
Author of The Text Reformatter, a tool for fanfiction readers and writers.
Language: English, French (Well, I'm French).