Re: Release plan

Simon Large wrote:

> I think we can and should do our own RC sooner, against SVN RC4. I'm
> sure we have done that in the past, and not waited for the final release
> before doing our RC1. It's been a long time since our last release from
> trunk and we need to get some more exposure to testing.

We can do that. Depending on how the conversion to VS2005 goes.

>> Keep working on trunk, implementing new features. But 1.3.x releases
>> will be made from the 1.3.x branch, not from trunk anymore. And they
>> will *only contain bugfixes*, no new features or other changes.
>
> This is a very much more conservative policy than we have used before -
> similar to the SVN one. That means no new TSVN features until SVN 1.4,
> which is likely to be 6 months away. Is that really what you want to do?
> In the past this has caused problems because an important ease-of-use
> feature did not qualify as a bugfix and users had to wait a long time
> for it. Also, merging the bugfixes and doc updates has been a real PITA
> and we quickly got fed up with it.

I don't think we need to merge many doc changes. And the translators
then just have to commit twice, once to trunk and (only if there are
bugs or untranslated strings left) to the branch. As per definition,
there won't be any new features (that includes resource changes) on the
branch.
I've already been doing that for the last three 1.2.x releases, and it
worked pretty well.
Besides that: I've some changes on my todo list which require big
changes on trunk, and I definitely don't want those changes to go into a
release too early. So I'd have to create a separate branch to implement
those features there to not disturb the trunk - so I'd rather work on
trunk and just merge bugfixes over than having to merge from trunk to
the branch almost every day.

> Have you looked at www/release_faq.html lately? That explains why we
> generally cut releases from trunk. We want SVN to adopt a conservative
> policy, but we don't need to.

I know we don't need to. But as I mentioned above, there are some
changes planned which require a long time to implement and are a little
delicate (i.e. a big chance for many many bugs).

Also, I've received some mails from corporate users indicating that
they're afraid to update TSVN because it always contains "new" bugs or
things that haven't been tested long enough. So they stay on *very* old
releases (1.1.x) and still send me crashreports for those. To minimize
those crashreports, I'd like to try the different release procedure. If
it doesn't work, we can always change it back.

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