[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Upcoming release 0.25.

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2003-07-04 00:21:40 CEST

Paul L Lussier <pll@lanminds.com> writes:

> - Since I've done hard part of reviewing, consolidating, and listing
> changes for the CHANGES file, how much more is likely to be added
> between now and Saturday, which is the designated release day?
> (IOW, am I waiting for more stuff so I can add that to the CHANGES file
> or is what's there what's going to be released?)

Good question. AFAIK, nobody has any big impending changes that "must
get out the door" with svn 0.25.

> - Is there a specific 'time of release'? or, is it just whenever I
> can get it out as long as it's still within the 24 hours designated
> as the release date ?

Whatever you want. It's not like there's someone with a stopwatch
watching, making sure it's released by a specific hour. I think we
just hope you could get it out "this weekend sometime".

> 3. Create the release branch, check out a working copy of the branch...
>
> First, does this really mean 'branch' or does this mean 'tag'?
> There doesn't seem to be anything under svn/branches which looks
> like a previous release, but svn/tags definitely looks like
> what I want...

No, create a real branch. The reason you see no branches in /branches
is because they were *deleted* by Michael Price when he was done with
them. If you look back in earlier revisions, you'll see the branch
directories. :-)

The general idea is:

  1. Copy trunk to a branch.

  2. Do all the release testing from that. You can either check it
     out fresh, or 'svn switch' your working copy to the branch.

  3. If there are bugs, you tell us. We panic, commit fixes to
     /trunk, and then you "port" the changes to the release branch via
     'svn merge'.

  4. After the release tarball goes out the door, copy your branch to
     to a tag, then delete the branch. You won't need it anymore.

  5. If a couple days later we discover that we need to send out a
     point release (0.25.1), then just re-copy the tag to a branch,
     and repeat steps 2, 3, 4.

> - make sure the working copy contains apr, apr-util, neon, and the
> Docbook tools (XSL, FOP). Those are all needed to build a
> distribution.
>
> I have these in my current working copy. However, I don't
> remember where/when/how they got there. I also haven't really
> built svn from my wc other than building the docs on occasion.

Have you never built svn from source code? apr, apr-util can be
checked out from CVS, but it's best to "grab copies" of the ones that
ship in the apache 2.0.46 tarball, since that's our base platform.

According to install, we need neon 0.23.9. You can either fetch the
tarball, or copy the one you have, assuming it's correct.

For the documentation (book), I'm not sure if we have a policy of
releasing *compiled* docs in the source tarball. You may not need to
worry about compiling the book with xslt/fop tools.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 4 00:23:15 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.