The VXL Project

> There is no need to stop commits - I'll tag today's version.
>
> Any objections or comments?

Make it a branch tag, so we can easily commit minor bug fixes.
For the rest, I fully agree with your arguments.


--	Peter.

On Thu, 9 Oct 2003, Peter Vanroose wrote:

> > There is no need to stop commits - I'll tag today's version.
> >
> > Any objections or comments?
>
> Make it a branch tag, so we can easily commit minor bug fixes.
> For the rest, I fully agree with your arguments.

There should be both a "branch point" tag and a branch tag.  This approach
marks the beginning of the branch with a non-branch tag so we can always
find the changes made to the branch.

-Brad

I agree with you assessment that we should have a release.

> I propose that we use the following release numbering from now on.
> Major.minor.date

I'm not sure what purpose the date indicator serves. I would prefer
either
  Major.minor.patch  or Major.minorpPatch (1.0p0)

or else, just Major.date.

For me, it's easier to say "version 1.0.34" than "version 1.0 of 9 October
2003". But this is a minor quibble that can be disregarded if
necessary.

Amitha.

On Thu 09 Oct 2003, Brad King wrote:
> There should be both a "branch point" tag and a branch tag.  This approach
> marks the beginning of the branch with a non-branch tag so we can always
> find the changes made to the branch.

This is true. Also, if we (Ian :-) ) created a branch point tag (say
1-0-0-bp), we can later create a branch tag from that branch point.

Amitha.

The purpose of the date is not really to distinguish between packaged
releases (which I don't expect to happen very often) but to distinguish
between CVS downloads. (Something Kitware would like)

Given that, maybe it is unnecessary to put the date in the packaged release
version string.

I suspect however that we will see almost no patch increments, unless
someone messes up the packaging.

I don't mind creating a separate branch tag, but I strongly suspect that
most maintainers will not distinguish between bug-fixes and new features. I
know I won't.

Ian.

> -----Original Message-----
> From: Amitha Perera [mailto:perera@...]
> Sent: Thursday, October 09, 2003 6:09 PM
> To: Ian Scott
> Cc: Vxl-maintainers (E-mail)
> Subject: Re: [Vxl-maintainers] VXL Release 1.0.09-Oct-2003
>
>
> I agree with you assessment that we should have a release.
>
> > I propose that we use the following release numbering from now on.
> > Major.minor.date
>
> I'm not sure what purpose the date indicator serves. I would prefer
> either
>   Major.minor.patch  or Major.minorpPatch (1.0p0)
>
> or else, just Major.date.
>
> For me, it's easier to say "version 1.0.34" than "version 1.0
> of 9 October
> 2003". But this is a minor quibble that can be disregarded if
> necessary.
>
> Amitha.
>

I've made the release.

I'll leave it there for a few days before any announcements.

For the purposes of documenting things I've learnt:

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

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)

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

	cd vxl
	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.
        cd /tmp
        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.

Ian.