From: John Peterson <peterson@cf...> - 2004-05-14 02:35:58
KIRK, BENJAMIN (JSC-EG) (NASA) writes:
> I am in full agreement with this proposal... I suggest that we use the -rc#
> numbering scheme (or something) to differentiate between the "golden"
> releases (like most releases to date) and these (automatically?) frequently
> created releases.
Good idea. How can you blame us for that bug? It's just a release candidate, not a
real release ;)
> So, the next release (which could be today's CVS snapshot) will be
> libmesh-0.4.3-rc1 and we should tag the CVS repository as such... We will
> continue in this way, and as John says people may report issues on supported
> platforms that haven't been tested with the latest release candidate. These
> issues will get fixed and will make their way into the next release
> candidate... When complaints become "sufficiently infrequent" then we
> magically have the next "golden" release (e.g. libmesh-0.4.3).
> In order to help with this, we should probably create a ./contrib/bin script
> that handles all the details:
> 1.) fresh checkout
> 2.) removes all the CVS directories and .cvsignore files from this checkout
> (nice, but not necessary)
> 3.) packs it up
> 4.) tracks the version number
> 5.) rtags the repository
If the details of that are fresh on your mind (I can never remember how to
use cvs tags) and you have enough time, please add said script. If possible,
also have it initiate the ftp upload to sourceforge.
> A long-term goal is to create an automated build/test system that runs
> nightly or weekly on all the supported platforms. Maybe when I have time
We should ask Wolfgang. I think he has something like that for Deal.
> -----Original Message-----
> From: libmesh-devel-admin@...
> [mailto:libmesh-devel-admin@...] On Behalf Of John
> Sent: Wednesday, May 12, 2004 12:37 PM
> To: libmesh-devel@...
> Subject: [Libmesh-devel] Release schedule
> It seems the toughest road-block to making a release
> is that someone (read Ben) has to download and build
> the library on N different platforms to make sure everything
> is still hunky-dory everywhere.
> I would vote for a more active release schedule, say every month or 2 weeks,
> where we just release what we have without the exhaustive rebuild on every
> system. That way we let users who are actually on those systems discover
> the bugs ;) and report them, and then a new release is not far away.
> If everyone agrees, then I suggest Ben and I take turns every other month
> making the release on a set day, say the 15th of the month or whatever. If
> anyone else wants to take a turn, be my guest! I will make sure you have
> file release privileges.
> In the end, this will be less work for us in 2 ways: (1) no dreaded
> exhaustive rebuild on many systems that takes time.
> (2) users who obtain the latest release instead of the cvs
> will report fewer "previous version" bugs, and we will not
> have to say "Check out the cvs version" until we go crazy.
> Comments, Questions?
> John W. Peterson