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?
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
>
Received on 2017-12-28 22:38:01 CET