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

Re: RE: 1.3.5

From: Slarge <slarge_at_slarge.plus.com>
Date: 2006-06-17 00:22:43 CEST
('binary' encoding is not supported, stored as-is) On Fri Jun 16 14:40 , Lübbe Onken <l.onken@rac.de> sent:

>Jens Peters wrote:
>> I would do the following:
>> - Finish all backports/changes
>> - trigger the nightly build manually
>> - announce this nightly build/magic revision number on the dev/users
>> list as a version before releasing, wait a few days for feedback
>> - finally react or start the release procedure with tagging etc..
>We could meet somewhere in between. I wouldn't go through all the
>release_procedure stuff either, but
>I would tag that magic revision number as RC-x, name the files RC-x, place
>them in a folder named RC-x and go shout everywhere that RC-x is available,
>just to make sure that people wake up and test it.

I don't think we need release candidates as such, but I do think we can make better use of the stable branch 'nightly'.

1. Rebuild (to nightly standard, not full release standard) when changes are committed to the stable branch. As these changes are quite rare,
this will not need to be done too often.
2. Keep the stable branch build on SourceForge so we have the stats.
3. Add a reference to the download page, with a note explaining that although this is not the official release, it is just the last release plus
bugfixes so it is effectively an ongoing release-candidate. You might need to keep the debug info to make sense of crash reports.

I would guess that the stable nightly currently gets very little testing, so this option should improve the exposure without creating extra work
for Stefan - just prompt the nightly builder to do the branch as well.

Also, no-one will download this one to look at new features - there aren't any. The only reason to download is because you can't live with a bug
in the current release, so anyonewho downloads it is likely to be using it for real.


To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Sat Jun 17 09:24:20 2006

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

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