On Wed, Aug 24, 2011 at 4:26 AM, Ivan Zhakov <ivan_at_visualsvn.com> wrote:
> On Wed, Aug 24, 2011 at 12:38, Bert Huijben <bert_at_qqmail.nl> wrote:
>>> -----Original Message-----
>>> From: Stefan Sperling [mailto:stsp_at_elego.de]
>>> Sent: woensdag 24 augustus 2011 9:50
>>> To: Markus Schaber
>>> Cc: dev_at_subversion.apache.org
>>> Subject: Re: rc1 is DOA. What now?
>>> On Wed, Aug 24, 2011 at 08:46:17AM +0200, Markus Schaber wrote:
>>> > To support this unlocking, it would additionally force our software to
>>> > carry both SVN 1.6 and SVN 1.7 libraries at the same time.
>>> If 1.7.0 was released with this upgrade bug, you would simply have to
>>> wait for a 1.7.x patch release which fixes the bug before upgrading
>>> from 1.6.x.
>>> This is basically just like any other show stopper you might find
>>> during the upgrade to 1.7. Except that you already know about it now :)
>>> But I understand your complaints and agree that the problem needs
>>> to be fixed in 1.7.x eventually.
>> * The average TortoiseSVN user in a corporate environment can't
>> upgrade/downgrade its own installation as that as managed via automated
>> * TortoiseSVN versions can't be installed side by side.
>> (The same problem applies to big multi user installations on shared linux
>> installations using plain svn)
>> How would you answer an e-mail from your sysadmin that tonight before you go
>> home you have to remove all locks from all your working copies because
>> otherwise tomorrow your working copies are broken?
>> (Assuming you have over 40 independent working copies, not counting possible
>> directory externals, like I had when I worked at TCG)
>> I call this a show stopper; and as I suggested before suggesting these users
>> to wait until 1.7.1 is the same as calling this a show stopper.
>> And it also breaks the perfect stability track record we had with a
>> known-in-advance broken release.
>> In my opinion this issue must be fixed by 1.7.0.
> I fully agree with Bert: this upgrade bug is show stopper for 1.7.0. I
> do not see the problem with restarting soak period because we found
> bugs: this is purpose soak period and stabilization to release
> software without known important issues.
To be clear: this type of bug would not have restarted the 4-week soak
if we'd already been in it. It is well-understood and the fix is
well-scoped. While I don't claim it has been tested exhaustively,
restarting the soak is reserved for high-impact fixes which require a
large degree of community testing.
uberSVN: Apache Subversion Made Easy
Received on 2011-08-24 13:37:21 CEST