You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Stefan <lu...@posteo.de> on 2017/12/28 17:19:12 UTC
Re: svn commit: r1819391 -
/subversion/site/staging/docs/release-notes/1.10.html
On 28/12/2017 04:52, danielsh@apache.org wrote:
> Author: danielsh
> Date: Thu Dec 28 03:52:02 2017
> New Revision: 1819391
>
> URL: http://svn.apache.org/viewvc?rev=1819391&view=rev
> Log:
> * docs/release-notes/1.10.html
> (#svn-1.9-deprecation): New section.
> (#svn-1.8-deprecation): Tweak wording for accuracy and contrast.
>
> Modified:
> subversion/site/staging/docs/release-notes/1.10.html
>
> Modified: subversion/site/staging/docs/release-notes/1.10.html
> URL: http://svn.apache.org/viewvc/subversion/site/staging/docs/release-notes/1.10.html?rev=1819391&r1=1819390&r2=1819391&view=diff
> ==============================================================================
> --- subversion/site/staging/docs/release-notes/1.10.html (original)
> +++ subversion/site/staging/docs/release-notes/1.10.html Thu Dec 28 03:52:02 2017
> @@ -808,6 +808,21 @@ if they occur.</p>
>
> </div> <!-- troubleshooting -->
>
> +<div class="h2" id="svn-1.9-deprecation">
> +<h2>Subversion 1.9.x is deprecated
> + <a class="sectionlink" href="#svn-1.9-deprecation"
> + title="Link to this section">¶</a>
> +</h2>
> +
> +<p>The Subversion 1.9.x line is deprecated. This doesn't
> +mean that your 1.9 installation is doomed; if it works well and is all
> +you need, that's fine. "No longer supported" just means we've stopped
> +accepting non-critical bug reports against 1.9.x versions, and will not
> +make any more 1.9.x releases, except for security and critical bugfix
> +releases.</p>
> +
> +</div> <!-- svn-1.9-deprecation -->
> +
> [...]
This sounds like a change of plan to me related to how we treated things
in the past. Was this discussed on list and I simply overlooked it?
Correct me if I'm wrong, but in the past we always accepted non-critical
bug reports against the previous version and also fixed them. We also
released patch-releases for the previous version even if there wasn't a
security related issue but rather the number of bugfixes summed up to a
point where it was reasonable to start rolling a patch release.
I'm not sure if going down the road where we only provide bugfixes for
the latest builds is something we'd do. At the hackathon this was
slightly touched too and was discussed that if we introduce shorter
release cycles, we also should introduce LTS versions.
Regards,
Stefan
Re: svn commit: r1819391 -
/subversion/site/staging/docs/release-notes/1.10.html
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Nathan Hartman wrote on Thu, 28 Dec 2017 23:50 -0500:
> On Dec 28, 2017, at 5:59 PM, Stefan <lu...@posteo.de> wrote:
> >
> > Suggestion for a different phrasing:
> >
> > section id: svn-1.9-old-stable
> >
> > The Subversion 1.9.x line is now the old stable version. This means
> > that 1.9.x will still receive security relevant fixes as well as
> > bugfixes. While we will evaluate any bugreport with regards to its
> > severity, there might be issues with a lower severity which will
> > only get fixed in 1.10.x (this especially applies to issues which
> > would require API additions/changes and/or require a significant
> > investment to get backported to the old stable version).
> >
> > Therefore, if you are running into an issue with the old stable
> > version which has already been fixed in the latest version, we might
> > ask you to upgrade to that version to resolve the issue.
> >
> > Regards,
> > Stefan
> >
>
> Just chiming in here. As a user, Stefan's suggested text makes sense,
> sounds reasonable from both a dev and a user point of view, and is far
> less scary sounding than "deprecated" or "doomed" -- yes I know the
> other text said it's NOT doomed, but nevertheless!!! :-)
+1
I'd just suggest to change "require API changes/additions" to "be
destabilizing".
@Nathan the language about "doomed" is copied from the 1.8 section of
the 1.10 release notes; if it's scary then perhaps that paragraph should
change too.
Cheers,
Daniel
Re: svn commit: r1819391 - /subversion/site/staging/docs/release-notes/1.10.html
Posted by Nathan Hartman <ha...@gmail.com>.
On Dec 28, 2017, at 5:59 PM, Stefan <lu...@posteo.de> wrote:
>
> Suggestion for a different phrasing:
>
> section id: svn-1.9-old-stable
>
> The Subversion 1.9.x line is now the old stable version. This means that 1.9.x will still receive security relevant fixes as well as bugfixes. While we will evaluate any bugreport with regards to its severity, there might be issues with a lower severity which will only get fixed in 1.10.x (this especially applies to issues which would require API additions/changes and/or require a significant investment to get backported to the old stable version).
> Therefore, if you are running into an issue with the old stable version which has already been fixed in the latest version, we might ask you to upgrade to that version to resolve the issue.
>
> Regards,
> Stefan
>
Just chiming in here. As a user, Stefan's suggested text makes sense, sounds reasonable from both a dev and a user point of view, and is far less scary sounding than "deprecated" or "doomed" -- yes I know the other text said it's NOT doomed, but nevertheless!!! :-)
Re: svn commit: r1819391 -
/subversion/site/staging/docs/release-notes/1.10.html
Posted by Stefan <lu...@posteo.de>.
On 28/12/2017 22:37, Daniel Shahaf wrote:
> Stefan wrote on Thu, Dec 28, 2017 at 18:19:12 +0100:
>> On 28/12/2017 04:52, danielsh@apache.org wrote:
>>> Author: danielsh
>>> Date: Thu Dec 28 03:52:02 2017
>>> New Revision: 1819391
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1819391&view=rev
>>> Log:
>>> * docs/release-notes/1.10.html
>>> (#svn-1.9-deprecation): New section.
>>> (#svn-1.8-deprecation): Tweak wording for accuracy and contrast.
>>>
>>> Modified:
>>> subversion/site/staging/docs/release-notes/1.10.html
>>>
>>> Modified: subversion/site/staging/docs/release-notes/1.10.html
>>> URL: http://svn.apache.org/viewvc/subversion/site/staging/docs/release-notes/1.10.html?rev=1819391&r1=1819390&r2=1819391&view=diff
>>> ==============================================================================
>>> --- subversion/site/staging/docs/release-notes/1.10.html (original)
>>> +++ subversion/site/staging/docs/release-notes/1.10.html Thu Dec 28 03:52:02 2017
>>> @@ -808,6 +808,21 @@ if they occur.</p>
>>>
>>> </div> <!-- troubleshooting -->
>>>
>>> +<div class="h2" id="svn-1.9-deprecation">
>>> +<h2>Subversion 1.9.x is deprecated
>>> + <a class="sectionlink" href="#svn-1.9-deprecation"
>>> + title="Link to this section">¶</a>
>>> +</h2>
>>> +
>>> +<p>The Subversion 1.9.x line is deprecated. This doesn't
>>> +mean that your 1.9 installation is doomed; if it works well and is all
>>> +you need, that's fine. "No longer supported" just means we've stopped
>>> +accepting non-critical bug reports against 1.9.x versions, and will not
>>> +make any more 1.9.x releases, except for security and critical bugfix
>>> +releases.</p>
>>> +
>>> +</div> <!-- svn-1.9-deprecation -->
>>> +
>>> [...]
>> This sounds like a change of plan to me related to how we treated things
>> in the past. Was this discussed on list and I simply overlooked it?
> I didn't mean to change the process; only to document the existing process.
>
>> Correct me if I'm wrong, but in the past we always accepted non-critical
>> bug reports against the previous version and also fixed them. We also
>> released patch-releases for the previous version even if there wasn't a
>> security related issue but rather the number of bugfixes summed up to a
>> point where it was reasonable to start rolling a patch release.
> The way I believe we have been doing things is: once 1.10.0-GA is announced,
> 1.9.x will receive security fixes and critical bugfixes, plus any other
> "normal" bugfixes which manage to muster enough votes in STATUS; the latter
> kind is rare but not unheard of.
>
> Look at users@ today. When people report a bug in 1.8.x we just tell them to
> try with 1.9.x, and if it's fixed there then that's it; and when devs nominate
> a backport to 1.9.x it is rare that they nominate it to 1.8.x as well.
>
> However, between your and Brane's replies it is clear that the language doesn't
> convey the intended meaning. Perhaps someone could suggest alternative text?
>
> [...]
As far as I'm concerned we eventually ask people to check/confirm bugs
against later builds to verify that the issue was fixed in the following
branch already to better evaluate the priority of investigating the
issue. Since 1.8.x is soon becoming EOL, I wouldn't bother too much
about remaining bugs in that version, especially if they are
a) not critical and
b) already resolved in later versions
So asking people to verify the issue against the 1.9.x branch is all
fine IMO and doesn't really contradict anything with regards to how we
handle/prioritize bugs/bugfixes from our side.
In this case I would not call 1.9.x deprecated. Deprecated to me sounds
like it's going to be EOL soon (which given our current release cycle is
quite "harsh" in that new releases are coming atm in-between 2 and 3
years --- I'm aware this might change soon(tm) but then, we are not
there yet and haven't decided any details either).
I however agree that we can do better in clarifying that not all issues
in 1.9.x would be resolved and that 1.10.x contains fixes which would be
relevant for 1.9.x as well but are mostly out of question to be
backported (f.e. if they rely on a complete refactoring and/or new APIs).
Suggestion for a different phrasing:
section id: svn-1.9-old-stable
The Subversion 1.9.x line is now the old stable version. This means that 1.9.x will still receive security relevant fixes as well as bugfixes. While we will evaluate any bugreport with regards to its severity, there might be issues with a lower severity which will only get fixed in 1.10.x (this especially applies to issues which would require API additions/changes and/or require a significant investment to get backported to the old stable version).
Therefore, if you are running into an issue with the old stable version which has already been fixed in the latest version, we might ask you to upgrade to that version to resolve the issue.
Regards,
Stefan
Re: svn commit: r1819391 -
/subversion/site/staging/docs/release-notes/1.10.html
Posted by Stefan <lu...@posteo.de>.
On 28/12/2017 22:37, Daniel Shahaf wrote:
> Stefan wrote on Thu, Dec 28, 2017 at 18:19:12 +0100:
>> On 28/12/2017 04:52, danielsh@apache.org wrote:
>>> Author: danielsh
>>> Date: Thu Dec 28 03:52:02 2017
>>> New Revision: 1819391
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1819391&view=rev
>>> Log:
>>> * docs/release-notes/1.10.html
>>> (#svn-1.9-deprecation): New section.
>>> (#svn-1.8-deprecation): Tweak wording for accuracy and contrast.
>>>
>>> Modified:
>>> subversion/site/staging/docs/release-notes/1.10.html
>>>
>>> Modified: subversion/site/staging/docs/release-notes/1.10.html
>>> URL: http://svn.apache.org/viewvc/subversion/site/staging/docs/release-notes/1.10.html?rev=1819391&r1=1819390&r2=1819391&view=diff
>>> ==============================================================================
>>> --- subversion/site/staging/docs/release-notes/1.10.html (original)
>>> +++ subversion/site/staging/docs/release-notes/1.10.html Thu Dec 28 03:52:02 2017
>>> @@ -808,6 +808,21 @@ if they occur.</p>
>>>
>>> </div> <!-- troubleshooting -->
>>>
>>> +<div class="h2" id="svn-1.9-deprecation">
>>> +<h2>Subversion 1.9.x is deprecated
>>> + <a class="sectionlink" href="#svn-1.9-deprecation"
>>> + title="Link to this section">¶</a>
>>> +</h2>
>>> +
>>> +<p>The Subversion 1.9.x line is deprecated. This doesn't
>>> +mean that your 1.9 installation is doomed; if it works well and is all
>>> +you need, that's fine. "No longer supported" just means we've stopped
>>> +accepting non-critical bug reports against 1.9.x versions, and will not
>>> +make any more 1.9.x releases, except for security and critical bugfix
>>> +releases.</p>
>>> +
>>> +</div> <!-- svn-1.9-deprecation -->
>>> +
>>> [...]
>> This sounds like a change of plan to me related to how we treated things
>> in the past. Was this discussed on list and I simply overlooked it?
> I didn't mean to change the process; only to document the existing process.
>
>> Correct me if I'm wrong, but in the past we always accepted non-critical
>> bug reports against the previous version and also fixed them. We also
>> released patch-releases for the previous version even if there wasn't a
>> security related issue but rather the number of bugfixes summed up to a
>> point where it was reasonable to start rolling a patch release.
> The way I believe we have been doing things is: once 1.10.0-GA is announced,
> 1.9.x will receive security fixes and critical bugfixes, plus any other
> "normal" bugfixes which manage to muster enough votes in STATUS; the latter
> kind is rare but not unheard of.
>
> Look at users@ today. When people report a bug in 1.8.x we just tell them to
> try with 1.9.x, and if it's fixed there then that's it; and when devs nominate
> a backport to 1.9.x it is rare that they nominate it to 1.8.x as well.
>
> However, between your and Brane's replies it is clear that the language doesn't
> convey the intended meaning. Perhaps someone could suggest alternative text?
>
> [...]
As far as I'm concerned we eventually ask people to check/confirm bugs
against later builds to verify that the issue was fixed in the following
branch already to better evaluate the priority of investigating the
issue. Since 1.8.x is soon becoming EOL, I wouldn't bother too much
about remaining bugs in that version, especially if they are
a) not critical and
b) already resolved in later versions
So asking people to verify the issue against the 1.9.x branch is all
fine IMO and doesn't really contradict anything with regards to how we
handle/prioritize bugs/bugfixes from our side.
In this case I would not call 1.9.x deprecated. Deprecated to me sounds
like it's going to be EOL soon (which given our current release cycle is
quite "harsh" in that new releases are coming atm in-between 2 and 3
years --- I'm aware this might change soon(tm) but then, we are not
there yet and haven't decided any details either).
I however agree that we can do better in clarifying that not all issues
in 1.9.x would be resolved and that 1.10.x contains fixes which would be
relevant for 1.9.x as well but are mostly out of question to be
backported (f.e. if they rely on a complete refactoring and/or new APIs).
Suggestion for a different phrasing:
section id: svn-1.9-old-stable
The Subversion 1.9.x line is now the old stable version. This means that 1.9.x will still receive security relevant fixes as well as bugfixes. While we will evaluate any bugreport with regards to its severity, there might be issues with a lower severity which will only get fixed in 1.10.x (this especially applies to issues which would require API additions/changes and/or require a significant investment to get backported to the old stable version).
Therefore, if you are running into an issue with the old stable version which has already been fixed in the latest version, we might ask you to upgrade to that version to resolve the issue.
Regards,
Stefan
Re: svn commit: r1819391 -
/subversion/site/staging/docs/release-notes/1.10.html
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Stefan wrote on Thu, Dec 28, 2017 at 18:19:12 +0100:
> On 28/12/2017 04:52, danielsh@apache.org wrote:
> > Author: danielsh
> > Date: Thu Dec 28 03:52:02 2017
> > New Revision: 1819391
> >
> > URL: http://svn.apache.org/viewvc?rev=1819391&view=rev
> > Log:
> > * docs/release-notes/1.10.html
> > (#svn-1.9-deprecation): New section.
> > (#svn-1.8-deprecation): Tweak wording for accuracy and contrast.
> >
> > Modified:
> > subversion/site/staging/docs/release-notes/1.10.html
> >
> > Modified: subversion/site/staging/docs/release-notes/1.10.html
> > URL: http://svn.apache.org/viewvc/subversion/site/staging/docs/release-notes/1.10.html?rev=1819391&r1=1819390&r2=1819391&view=diff
> > ==============================================================================
> > --- subversion/site/staging/docs/release-notes/1.10.html (original)
> > +++ subversion/site/staging/docs/release-notes/1.10.html Thu Dec 28 03:52:02 2017
> > @@ -808,6 +808,21 @@ if they occur.</p>
> >
> > </div> <!-- troubleshooting -->
> >
> > +<div class="h2" id="svn-1.9-deprecation">
> > +<h2>Subversion 1.9.x is deprecated
> > + <a class="sectionlink" href="#svn-1.9-deprecation"
> > + title="Link to this section">¶</a>
> > +</h2>
> > +
> > +<p>The Subversion 1.9.x line is deprecated. This doesn't
> > +mean that your 1.9 installation is doomed; if it works well and is all
> > +you need, that's fine. "No longer supported" just means we've stopped
> > +accepting non-critical bug reports against 1.9.x versions, and will not
> > +make any more 1.9.x releases, except for security and critical bugfix
> > +releases.</p>
> > +
> > +</div> <!-- svn-1.9-deprecation -->
> > +
> > [...]
>
> This sounds like a change of plan to me related to how we treated things
> in the past. Was this discussed on list and I simply overlooked it?
I didn't mean to change the process; only to document the existing process.
> Correct me if I'm wrong, but in the past we always accepted non-critical
> bug reports against the previous version and also fixed them. We also
> released patch-releases for the previous version even if there wasn't a
> security related issue but rather the number of bugfixes summed up to a
> point where it was reasonable to start rolling a patch release.
The way I believe we have been doing things is: once 1.10.0-GA is announced,
1.9.x will receive security fixes and critical bugfixes, plus any other
"normal" bugfixes which manage to muster enough votes in STATUS; the latter
kind is rare but not unheard of.
Look at users@ today. When people report a bug in 1.8.x we just tell them to
try with 1.9.x, and if it's fixed there then that's it; and when devs nominate
a backport to 1.9.x it is rare that they nominate it to 1.8.x as well.
However, between your and Brane's replies it is clear that the language doesn't
convey the intended meaning. Perhaps someone could suggest alternative text?
Cheers,
Daniel
> I'm not sure if going down the road where we only provide bugfixes for
> the latest builds is something we'd do. At the hackathon this was
> slightly touched too and was discussed that if we introduce shorter
> release cycles, we also should introduce LTS versions.
>
> Regards,
> Stefan
>
Re: svn commit: r1819391 -
/subversion/site/staging/docs/release-notes/1.10.html
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Stefan wrote on Thu, Dec 28, 2017 at 18:19:12 +0100:
> On 28/12/2017 04:52, danielsh@apache.org wrote:
> > Author: danielsh
> > Date: Thu Dec 28 03:52:02 2017
> > New Revision: 1819391
> >
> > URL: http://svn.apache.org/viewvc?rev=1819391&view=rev
> > Log:
> > * docs/release-notes/1.10.html
> > (#svn-1.9-deprecation): New section.
> > (#svn-1.8-deprecation): Tweak wording for accuracy and contrast.
> >
> > Modified:
> > subversion/site/staging/docs/release-notes/1.10.html
> >
> > Modified: subversion/site/staging/docs/release-notes/1.10.html
> > URL: http://svn.apache.org/viewvc/subversion/site/staging/docs/release-notes/1.10.html?rev=1819391&r1=1819390&r2=1819391&view=diff
> > ==============================================================================
> > --- subversion/site/staging/docs/release-notes/1.10.html (original)
> > +++ subversion/site/staging/docs/release-notes/1.10.html Thu Dec 28 03:52:02 2017
> > @@ -808,6 +808,21 @@ if they occur.</p>
> >
> > </div> <!-- troubleshooting -->
> >
> > +<div class="h2" id="svn-1.9-deprecation">
> > +<h2>Subversion 1.9.x is deprecated
> > + <a class="sectionlink" href="#svn-1.9-deprecation"
> > + title="Link to this section">¶</a>
> > +</h2>
> > +
> > +<p>The Subversion 1.9.x line is deprecated. This doesn't
> > +mean that your 1.9 installation is doomed; if it works well and is all
> > +you need, that's fine. "No longer supported" just means we've stopped
> > +accepting non-critical bug reports against 1.9.x versions, and will not
> > +make any more 1.9.x releases, except for security and critical bugfix
> > +releases.</p>
> > +
> > +</div> <!-- svn-1.9-deprecation -->
> > +
> > [...]
>
> This sounds like a change of plan to me related to how we treated things
> in the past. Was this discussed on list and I simply overlooked it?
I didn't mean to change the process; only to document the existing process.
> Correct me if I'm wrong, but in the past we always accepted non-critical
> bug reports against the previous version and also fixed them. We also
> released patch-releases for the previous version even if there wasn't a
> security related issue but rather the number of bugfixes summed up to a
> point where it was reasonable to start rolling a patch release.
The way I believe we have been doing things is: once 1.10.0-GA is announced,
1.9.x will receive security fixes and critical bugfixes, plus any other
"normal" bugfixes which manage to muster enough votes in STATUS; the latter
kind is rare but not unheard of.
Look at users@ today. When people report a bug in 1.8.x we just tell them to
try with 1.9.x, and if it's fixed there then that's it; and when devs nominate
a backport to 1.9.x it is rare that they nominate it to 1.8.x as well.
However, between your and Brane's replies it is clear that the language doesn't
convey the intended meaning. Perhaps someone could suggest alternative text?
Cheers,
Daniel
> I'm not sure if going down the road where we only provide bugfixes for
> the latest builds is something we'd do. At the hackathon this was
> slightly touched too and was discussed that if we introduce shorter
> release cycles, we also should introduce LTS versions.
>
> Regards,
> Stefan
>
Re: svn commit: r1819391 -
/subversion/site/staging/docs/release-notes/1.10.html
Posted by Branko Čibej <br...@apache.org>.
On 28.12.2017 18:19, Stefan wrote:
> On 28/12/2017 04:52, danielsh@apache.org wrote:
>> Author: danielsh
>> Date: Thu Dec 28 03:52:02 2017
>> New Revision: 1819391
>>
>> URL: http://svn.apache.org/viewvc?rev=1819391&view=rev
>> Log:
>> * docs/release-notes/1.10.html
>> (#svn-1.9-deprecation): New section.
>> (#svn-1.8-deprecation): Tweak wording for accuracy and contrast.
>>
>> Modified:
>> subversion/site/staging/docs/release-notes/1.10.html
>>
>> Modified: subversion/site/staging/docs/release-notes/1.10.html
>> URL: http://svn.apache.org/viewvc/subversion/site/staging/docs/release-notes/1.10.html?rev=1819391&r1=1819390&r2=1819391&view=diff
>> ==============================================================================
>> --- subversion/site/staging/docs/release-notes/1.10.html (original)
>> +++ subversion/site/staging/docs/release-notes/1.10.html Thu Dec 28 03:52:02 2017
>> @@ -808,6 +808,21 @@ if they occur.</p>
>>
>> </div> <!-- troubleshooting -->
>>
>> +<div class="h2" id="svn-1.9-deprecation">
>> +<h2>Subversion 1.9.x is deprecated
>> + <a class="sectionlink" href="#svn-1.9-deprecation"
>> + title="Link to this section">¶</a>
>> +</h2>
>> +
>> +<p>The Subversion 1.9.x line is deprecated. This doesn't
>> +mean that your 1.9 installation is doomed; if it works well and is all
>> +you need, that's fine. "No longer supported" just means we've stopped
>> +accepting non-critical bug reports against 1.9.x versions, and will not
>> +make any more 1.9.x releases, except for security and critical bugfix
>> +releases.</p>
>> +
>> +</div> <!-- svn-1.9-deprecation -->
>> +
>> [...]
> This sounds like a change of plan to me related to how we treated things
> in the past. Was this discussed on list and I simply overlooked it?
This looks wrong; with the release of 1.10.x, 1.8.x will be deprecated,
not 1.9.x.
-- Brane