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

Re: 1.6.3 up for signing/testing_43886

From: <petesea_at_bigfoot.com>
Date: Thu, 18 Jun 2009 09:47:18 -0700 (PDT)

On Wed, 17 Jun 2009, Hyrum K. Wright wrote:

> Distro package maintainers, please do NOT include any pre-release
> builds, even blessed, into operating system distros. The reasons for
> not doing so were very eloquently outlined by Karl in a mail, which is
> summarized at the above address.

Since there's such a strong warning that a release candidate should not be
used for any production purpose, is there a particular reason the package
names don't reflect this?

Perhaps the filenames of the distro should make it clearer, eg:


I'm not saying the internal version string necessarily needs to change,
but it seems at least the package filenames should be different.
(Although changing both the internal version string and the initial
directory in the distro would make it even clearer this is a RC.)

If only the package filenames are changed and this particular RC is moved
to a production state, then all that's required is a change to the

I can certainly see myself downloading this version for testing and then
sometime later (after it's released) downloading the released version only
to realize I already have it... forgetting they are not the same thing.

I think it's better to have packages with different filenames, which are
in fact the same:

   subversion-1.6.3.rc1.tar.bz2 (Release Candidate 1)
   subversion-1.6.3.rc2.tar.bz2 (Release Candidate 2)
   subversion-1.6.3.tar.bz2 (Final Release - same as RC2)

As opposed to packages with the same filename, which are in fact

   subversion-1.6.3.tar.bz2 (Release Candidate 1)
   subversion-1.6.3.tar.bz2 (Release Candidate 2)
   subversion-1.6.3.tar.bz2 (Final Release - same as RC2)

Received on 2009-06-18 23:58:33 CEST

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.