Milen A. Radev wrote:
> On 01/09/05, Simon Large <simon@skirridsystems.co.uk> wrote:
> [...]
> 
>>>Stefan Küng wrote:
>>>
>>>
>>>>TortoiseSVN 1.2.2 has been released!
>>>>You can grab it from our download page:
>>>>http://tortoisesvn.tigris.org/download.html
>>>>
>>>>It's built against Subversion 1.2.3.
>>>>The MD5 checksum of the installer is
>>>>1E3D075EEA07006DFFBB337EA34C71A4  TortoiseSVN-1.2.2.4295-svn-1.2.3.msi
>>>>
>>>>There were about 400 commits between 1.2.1 and 1.2.2, so expect quite
>>>>a few changes ;)
>>>
>>>
>>>What, no release candidate first?
>>>
>>>*shudder*
>>
>>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.
Simon
-- 
        ___
   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 Thu Sep  1 11:05:47 2005