I did ask around in our group at Brown, which has a steady flow of new
vxl users. The predominant opinion is that a stable release is valuable
to get started, even if it is a bit out of date (months not years). The
problem expressed about solution 2) is that while vxl is stable it can
have build errors. So downloading that state exposes a new user to
fixing bugs or commenting CMake files, which is precisely what a new
user doesn't know how to do.
[mailto:vxl-maintainers-admin@...] On Behalf Of
Sent: Thursday, June 23, 2005 5:44 PM
Cc: Joseph L Mundy
Subject: RE: [Vxl-maintainers] vxl releases etc
Joe Mundy said:
> I don't like solution 2). Maybe we could more broadly share the work
> a release according to solution 1) in some way. I don't have a good
> understanding of what is involved. How did the process go last time?
Well, the process is basically a pain in the proverbial IMO. I made a
few mistakes along the way (hence the reason we have a 22.214.171.124, and not
just a 1.1). But basically I just followed the instruction list passed
on by Ian Scott - I'm not a cvs expert so most of it was voodoo to me,
but it seemed to do the trick. The most effort if I remember correctly
is the downloading and compiling which needs to be done a few times on
at least two platforms - the scariest bit is getting the tags right, I
think I had to undo what I'd done once or twice ...
I presume you don't like 2) because of the apparent difficulty of entry
for newcomers? But I think at the moment the difficulty of entry is even
greater because newcomers download an old version of the library, spend
some effort trying to compile it, then ask one of the lists how to fix
it only to be told that they should get the CVS version...
My suggestions were (in increasing order of personal preference):
1) maintain the status quo, but making some effort to make releases on a
semi-regular basis (perhaps every 12 mths)
2) remove the releases from public view, and tell everyone to get the
latest CVS version as that is stable
3) automatically tar up a new release on a regular time frame (say once
a month, once a week, every day - if it's automatic, who cares?), and
just make that the current release (possibly changing only a minor
version number, eg 1.1.1, 1.1.2, ...).
Instructions (From Ian):
1. Download everything first onto at least two platforms and test the
current CVS HEAD. THe dashboards can be wrong (They never noticed that
the root configure filres had been removed!) This includes updating
* Need to commit changes here before making branch point etc.
2. The following is a description of how to make a branch point and
branch (Thanks to Brad for the info)(This only applies to making a new
minor version release, not a patch release)
cvs up -PdA
cvs tag vxl-1-0-bp
cvs tag -b vxl-1-0
3. Move to the branch
cvs up -r vxl-1-0
4. Do some release specific work
Make sure that core/vxl_version.h is correct.
Update CHANGES.txt to mention the new release.
Copy in an INSTALL.html (e.g. from the website)
5. Tag the 1.0.0 release:
cvs tag vxl-1-0-0
5A. If you end up in a mess (e.g. because SF will not recognise that
configure really shouldn't be in the CVS attic) you can abandon the
branches and tags you have made so far. You can fix everything in the
main CVS branch, and commit it there. Then simply retag everything with
the -F option, which will make it forget about the previous locations of
the tags. It is not recommended to do this if these tags have had any
other users but yourself.
cvs up -PdA
cvs tag -F vxl-1-0-bp
cvs tag -bF vxl-1-0
6. Create a vxl download into directory.
Do this on a Unix box so that the execute permissions are
preserved. use cvs export to strip the CVS directories.
cvs export -r vxl-1-0-0 -d vxl-1.0.0 vxl
7. Tar it up, and test the tar file from scratch on at
least two platforms.
8. Submit it to the Sourceforge File Release system.
9. Get a copy of the documentation build, tar it up, and submit it to
the File Release System.
10. Did I mention that testing is good. Try downloading the files from
SourceForge. It can go wrong even now.
11. Submit a email describing the release to vxl-users, vxl-announce,
and submit a news item at VXL's SourceForge project page.
Brendan McCane Email: mccane@...
Department of Computer Science Phone: +64 3 479 8588/8578.
University of Otago Fax: +64 3 479 8529
Box 56, Dunedin, New Zealand.
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
Vxl-maintainers mailing list