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_at_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
Received on 2017-12-28 23:59:43 CET