On 6/16/06, Lübbe Onken <l.onken@rac.de> wrote:
> Stefan Küng wrote:
> > RCs for intermediate releases?
>
> Yes, also an intermediate release is a release. If something gets worse
> after a release, because a 'simple' bug hasn't been found, which could have
> been found by making people use official release candidates for a week or
> two, it's worth the work, because it saves us some embarrasment.
I seriously doubt that an RC would have saved us here. Not many people
actually use/install an RC. And those who do most likely don't commit
single files but commit from the parent folder. So that bug wouldn't
have shown up.
Also don't forget that we currently have a 'problem': all those who
already tried an 1.4.x nightly build won't be able to use an 1.3.x
version anymore without checking out all projects again, because once
you use an 1.4.x version, the working copy format gets changed and
can't be used anymore with previous clients.
> > I'm ok with putting RC's for major releases (like the upcoming 1.4.0)
> > to sourceforge. But for every intermediate release? That's a *lot* of
> > work.
>
> Did you try to use releaseforge to upload releases to SF? It's not that bad.
Yes, I sometimes use it. But it's not really 'save' to use: last time
I tried, I ended up with *two* releases with the exact same name,
which caused big problems.
> Yes, but we want a lot of people to test our software. IMO the nightlies are
> sort of well hidden from 'normal' uses, even though we mention them at
> several places. Nightlies also have a very developer-alpha-quality smell
> about them, which surely prevents a lot people from installing them.
The same applies to an RC. Maybe a little less, but I guess not much
more people are willing to use/test an RC than are willing to test
nightly builds.
> From our own release_procedure.txt:
> ---SNIP---
> * When we think we're ready for a release, we create a branch from
> trunk, named after the next release version with an 'x' as the last
> version number, e.g. 1.4.x.
> ...
> * After about a week, a first release candidate is built and uploaded
> for all to test.
> * If no major bugs are found in the RC, we create the official release.
> However if some major bugs are found, those are fixed and another RC
> is created.
> ---SNIP---
>
> We mention no time limit here. I suggest a two week shakedown time for a
> release candidate. I would also leave at least a week between RCs if minor
> bugs are found, possibly less if big ones (crashes) are found.
We don't need to mention the time limit in that document. If we do,
then we're bound to it. I'd like to keep the time flexible.
> 1) If everything works perfectly, we would have one RC for two weeks.
> 2) If everything works normally, we would have 2-3 RCs, for 3-5 weeks.
> 3) If something goes really wrong, we would have 2 RCs in the first week and
> continue from 2) :-)
>
> I'd like to have the RCs on sourceforge to get a rough idea how many people
> have downloaded and tested it. The nightlies on mapcar are a black hole to
> me. We get no information out.
Downloading an RC or nightly does *not* mean it also gets tested. So
stats about the downloads only can give you a very rough estimate on
testing, not more.
While I agree that this information would be useful, I really don't
like the idea of pushing out RC's for intermediate releases. I'm the
one who has to do it, and I'd rather spend my time with other
things...
Stefan
--
___
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 Fri Jun 16 12:35:21 2006