Stefan Fuhrmann wrote:
>> That's exactly what we do today for major releases.
>> See https://192.168.2.2/svk/tortoisesvn/trunk/Release_procedure.txt
>
> Not exactly. I forgot to point out that my concern is
> with the bugfix releases (.1 and up). The difference
> to the current release procedure is that after building
> the release we wait for e.g. 2 weeks and announce
> it only afterwards as "released" (i.e. update version.txt).
>
> Note, that there is no extra build after the RC
> (provided that no regressions are found). As I understand
> the RC handling for major releases, the final version
> will require an extra build & upload cycle.
And that's exactly what I don't like at all (sorry). Imagine we provide
an RC with already the version information as the actual release will
have (even ommit the 'RC' or '-dev'). Then we find a bug and have to do
yet another release. Then we'd have two releases with the same version
information out there. Only the build number would be different, but
most people don't notice that (they only look at the filename).
And *that* would cause much more problems IMHO, because when someone
reports a problem and mentions the version used, we always have to ask
for the buildnumber too.
>> I'm not sure we should do the same for bugfix releases as we already do
>> for major releases. I don't know of any project out there which does RCs
>> for bugfix releases.
>
> We do ;) at our company (with an even much more
> elaborate process behind).
but also with a lot more people (who get paid!) to do the work.
>> If I may propose another way:
>> We try to find people who don't want to test trunk nightlies but are
>> willing to test the stable nightlies. I think we should have at least
>> five such people.
>
> +1. These don't have to be the same 5 people for
> every release (holidays and other schedule problems).
> Thus, we should call for testers well in advance of
> a particular release. We would try to keep it the same 5
> people, though.
I was thinking of just announcing the RC on the mailing list and wait
until the X amount of people replied to it indicating that they have
installed it. Then wait Y days for problem reports and if nothing
serious comes up, make the final release.
> Also, we might think of some incentive (most obvious:
> listing them in some appropriate place). Testing is a *very*
> unpleasant task after all.
That list would be *huge*!
>> Every time we merge a fix back to the stable branch
>> and build the nightly for it, we send a mail out to dev@ and (if they
>> don't follow the mailing list) to their personal mail, telling about it.
>> They then download that stable nightly and use that one from that time on.
>
> Hm. Going for a small group of testers implies them to
> be in-depth testers. Hence, a test cycle may take a
> whole day: Even just clicking every button / menu item
> in a meaningful way will take a lot of time.
>
> Therefore, we should inform those testers just as
> you said but we shouldn't expect them to do a full test
> every time. I would consider it sufficient if they committed
> to one in-depth test just before the release.
I was thinking that those people using TSVN for their day-job (i.e.
common use case for them) should be enough. I don't think we would find
enough people willing to really test things with testrepos/workingcopies.
> Ah .. o.k. So, maybe we should allow the testers to
> commit to one (or both) of the following "styles":
>
> * all-day tester: uses the latest stable nightly
> * in-depth tester: performs one comprehensive test
> including infrequently used features (merging, locking,
> remote repository operations etc.)
>
>> * maybe (to have some control over who really is using those nightlies)
>> we could require them to send a short notice every time they install
>> such a nightly (e.g. subject: installed stable nightly, body=revision
>> XXXX, date of installation, x64/win32, processor-type (single/dual) ).
I think that would be overkill (for the mailing list) for the trunk.
It's ok for the stable branch because there won't be that many builds
(hopefully).
> Perhaps not every time they install but as part
> of their test feedback. The latter is important for us
> to know whether there has been a test at all
> - not to blame people that did not test.
>
>>> -- Stefan^2
>>
>> Hmmm - should I sign with 'Stefan^1' from now on? :)
>
> No need for Borg signatures here ;) I just follow
> Lübbes proposal ...
>
> -- Stefan^2
I like the Borg comment :)
Stefan (one of two)
:)
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Wed Jun 21 16:49:26 2006