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

Re: Release procedures improvements.

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2005-04-05 15:20:19 CEST

kfogel@collab.net writes:

> 1. Should a release tarball be offered up publicly for signing and
> testing, and then blessed? Or should it circulate privately
> among the full committers, get tested & signed, and *then*
> uploaded somewhere public and announced?

Doesn't matter, so long as the unblessed and blessed tarballs are
differently named. I like the subversion-X.Y.Z-PRERELEASE.tar.gz idea
proposed later in this thread, FWIW.

> 2. When should the release tag be made?
>
> This is related to Question (1). It may be more sensible to
> resolve Question (1) first, and then address (2), as the answer
> to (2) might be more obvious depending on how (1) is resolved.

After the release tarball has been blessed.

> 3. Should dist.sh offer the ability to 'svn export' dependency
> trees, or should it insist on using tarballs? More generally,
> should dist.sh support release-generation needs other than those
> of the Subversion project?

We consider released, blessed tarballs to be our canonical definition
of "a Subversion release", and IMO that is probably how most project
would define the same for themselved. So our dependencies should be
pulled in from released, blessed tarballs.

And -0.5 on making dist.sh some kind of (more) general purpose tool.
It exists for the sole purpose of release Subversion.

> 4. (very minor question) Should the '-apri' and '-apru' options to
> dist.sh be changed to '-apu'/'-api' or '-apr-util'/'-apr-iconv'?
> The shorter options are consistent with some similar context in
> APR and APR-UTIL themselves (I don't remember exactly what).
> Justin prefers either the shortest or the longest forms. Ben
> Reser and Karl like the status quo.

Bikeshed. I'll only add that -api is a not-so-unique abbreviation
that maybe possibly perhaps could confuse someone down the road.

> As for *who* does the 1.2 release process, I'd like to propose that
> Ben Reser handle it, if he's willing.

+1

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 5 15:25:01 2005

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.