Milen A. Radev wrote:
> On 01/09/05, Simon Large <firstname.lastname@example.org> wrote:
>>>Stefan Küng wrote:
>>>>TortoiseSVN 1.2.2 has been released!
>>>>You can grab it from our download page:
>>>>It's built against Subversion 1.2.3.
>>>>The MD5 checksum of the installer is
>>>>There were about 400 commits between 1.2.1 and 1.2.2, so expect quite
>>>>a few changes ;)
>>>What, no release candidate first?
>>Even Subversion don't put out release candidates for minor releases. We
>>only do that for major releases where there is a big new feature that we
>>want a lot of people to test.
> Simon, may be you and Stefan should agree on the defintion of "minor
> release". Several lines above your definition Stefan said:
> "There were about 400 commits between 1.2.1 and 1.2.2, so expect quite
> a few changes ;)"
Hmm. Maybe 'minor release' was a bad choice of phrase.
> So what is it - minor release with quite a few changes?
But actually, yes, in a way. Look at the 1.2.0 release, which had
locking and TSVNcache added. Those were really big features and we
needed to increase their exposure before the official release, hence the
release candidates. Many people don't like running nightly builds, so
making it official (even if it is the same as a nightly) increases
exposure to testing. And of course Stefan has the debug files for
official releases, so crash reports can be analysed.
1.2.2 has a lot of bugfixes and relatively small new features, but
nothing that really threatens stability.
Subversion is a lot more cautious in their release procedures, and
rightly so. A problem in subversion itself could threaten the security
of user's data, so their minor releases really are only patches applied
to the last major release.
TSVN on the other hand is only a front end, so whilst bugs may be
inconvenient, they are not life-threatening to your data. That gives us
a bit more freedom with our release procedures.
We did try using a stabilising branch for TSVN 1.1.3, but it created a
lot of extra work and very little gain. So the compromise now is that
for the last week before a release, only bugfixes and low risk changes
get committed, which gives the nightly a chance to stabilise.
I think there are a couple of ways we could improve on this:
1. Document what we do and why we do it this way. There is a
release_procedure.txt, but it describes the 1.1.3 experiment and we
don't follow it now.
2. Make an announcement on the mailing list that we are in pre-release
stabilisation phase, so we can get more people to try out the (hopefully
stable) nightly builds. Often that announcement comes only a couple of
days before the release.
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Thu Sep 1 11:05:47 2005