Stefan Küng wrote:
> Simon Large wrote:
>> 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.
There were some things that got missed from the merging by mistake. But
on the whole it has worked 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.
OK, that's a good reason.
>> 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.
The downside is that smaller new features get held up for a long time
between releases. I suppose you could depart completely from following
Subversion's numbering and produce minor releases more often than SVN,
so you might get TSVN 1.5.0 against SVN 1.3.2. Subversion bugfix
releases might trigger just a new bugfix TSVN, or a minor release from
trunk, depending on how the development is going.
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 Wed Nov 30 22:18:05 2005