You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@subversion.apache.org by Daniel Shahaf <d....@daniel.shahaf.name> on 2020/04/30 16:47:26 UTC
Grace period for 1.13 users to upgrade to 1.14? (was: svn commit:
r1877222 - /subversion/site/publish/docs/release-notes/1.14.html)
danielsh@apache.org wrote on Thu, 30 Apr 2020 16:21 -0000:
> +++ subversion/site/publish/docs/release-notes/1.14.html Thu Apr 30 16:21:48 2020
> @@ -1330,6 +1330,20 @@ if they occur.</p>
> +<div class="h3" id="svn-1.13-deprecation">
> +<h3>Subversion 1.13.x is end of life
> + <a class="sectionlink" href="#svn-1.13-deprecation"
> + title="Link to this section">¶</a>
> +</h3>
> +
> +<p>The Subversion 1.13.x line is end of life (<abbr title="End Of Life">EOL</abbr>).
> +This doesn't mean that your 1.13 installation is doomed; if it works
> +well and is all you need, that's fine. "End of life" just means we've
> +stopped accepting bug reports against 1.13.x versions, and will not
> +make any more 1.13.x releases.</p>
I just copied the text we use for 1.9, but there's a distinction: users
of 1.9 have had time to upgrade to 1.10 before 1.14.0 becomes GA,
whereas users of 1.13 have not. So, should we promise some sort of
grace period for users of 1.13.x — i.e., a period following the release
of 1.14.0 during which we'll still fix security bugs in 1.13.0?
Granted, 1.13 was a regular release and was only promised to be
supported for six months (or until 1.14.0) in the first place, so the
grace period needn't be long.
Cheers,
Daniel
Releasing unidiffs (was: Re: Grace period for 1.13 users to upgrade
to 1.14?)
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Julian Foad wrote on Fri, 01 May 2020 15:58 +0000:
> 1 May 2020 16:39:36 Nathan Hartman <ha...@gmail.com>:
>
> > On Thu, Apr 30, 2020 at 12:47 PM Daniel Shahaf < d.s@daniel.shahaf.name > wrote:
> >
> >
> > > danielsh@apache.org wrote on Thu, 30 Apr 2020 16:21 -0000:
> > >
> >
> > > I just copied the text we use for 1.9, but there's a distinction: users
> > > of 1.9 have had time to upgrade to 1.10 before 1.14.0 becomes GA,
> > > whereas users of 1.13 have not. So, should we promise some sort of
> > > grace period for users of 1.13.x — i.e., a period following the release
> > > of 1.14.0 during which we'll still fix security bugs in 1.13.0?
> >
> >
> > Before I can offer an opinion on that, I have to ask: If that
> > scenario actually occurs, where a security issue is discovered in a
> > release line very soon after it goes EOL,
… then there doesn't have to be a fix at all. By definition, once a line
goes EOL, we don't promise to fix bugs in it; the community's collective
stance on bugs becomes "Please upgrade to a supported release line".
Even then, people can still fix individual bugs in older lines, if
that's what scratches their personal itches. See r873205 for example.
That bug was found when only 1.4.x and 1.5.x were supported, but people
backported it all the way back to 1.0.x (!). We didn't roll a 1.0.x
release afterwards, but the fix was backported by us for downstream
packagers' benefit. This way, packagers don't have to resolve conflicts
by themselves and users don't have to contend with a minor version
upgrade (with the entailed risk of running into regressions,
particularly when upgrading to a .0 release).
Furthermore, we can choose to issue a fix even if we didn't promise to.
(The community's support promises are a minimum, not a maximum.) And
now, to your question:
> > does the fix have to be an actual *release* with all the process
> > that implies, or can it just be a (signed) patch?
Both.
When we have code we expect users to run, it's in our interest to issue
it as a proper release, in order for the legal shield to apply to it;
and I don't believe there's anything preventing us from releasing
unidiffs rather than (or alongside) compressed tarballs. We would still
have to vote on the unidiff, sign it, etc., just like any other release
artifact.
However, creating a release doesn't require using release.py, creating
tarballs, creating a tag, incrementing SVN_VER_PATCH, or holding the
vote on any particular mailing list. The hard minimum for a release is
a PMC vote that blesses a particular artifact as a release.
(By the way, that's one of the few cases in which the distinction
between "full committer" and "PMC member" matters. The former is
a community status, like "patch manager"; the latter is a legal
construct.)
> Re. issuing fixes as patches, I think there's no precedent and no
> grounds for doing so this time. The option of doing so in future for
> the general case should be raised in a separate thread.
Cheers,
Daniel
Re: Grace period for 1.13 users to upgrade to 1.14?
Posted by Julian Foad <ju...@apache.org>.
In my opinion, although it's "nice" when everyone has clarity on all details of the process, it's just not important to decide this level of detail in advance. It's a fuzzy line and we'll make a reasonable decision if it happens, which it likely won't.
Re. issuing fixes as patches, I think there's no precedent and no grounds for doing so this time. The option of doing so in future for the general case should be raised in a separate thread.
- Julian
1 May 2020 16:39:36 Nathan Hartman <ha...@gmail.com>:
> On Thu, Apr 30, 2020 at 12:47 PM Daniel Shahaf < d.s@daniel.shahaf.name > wrote:
>
>
> > danielsh@apache.org wrote on Thu, 30 Apr 2020 16:21 -0000:
> >
>
> > I just copied the text we use for 1.9, but there's a distinction: users
> > of 1.9 have had time to upgrade to 1.10 before 1.14.0 becomes GA,
> > whereas users of 1.13 have not. So, should we promise some sort of
> > grace period for users of 1.13.x — i.e., a period following the release
> > of 1.14.0 during which we'll still fix security bugs in 1.13.0?
>
>
> Before I can offer an opinion on that, I have to ask: If that scenario actually occurs, where a security issue is discovered in a release line very soon after it goes EOL, does the fix have to be an actual *release* with all the process that implies, or can it just be a (signed) patch?
>
>
> Nathan
>
>
>
>
>
>
>
Re: Grace period for 1.13 users to upgrade to 1.14? (was: svn commit:
r1877222 - /subversion/site/publish/docs/release-notes/1.14.html)
Posted by Nathan Hartman <ha...@gmail.com>.
On Thu, Apr 30, 2020 at 12:47 PM Daniel Shahaf <d....@daniel.shahaf.name>
wrote:
> danielsh@apache.org wrote on Thu, 30 Apr 2020 16:21 -0000:
>
I just copied the text we use for 1.9, but there's a distinction: users
> of 1.9 have had time to upgrade to 1.10 before 1.14.0 becomes GA,
> whereas users of 1.13 have not. So, should we promise some sort of
> grace period for users of 1.13.x — i.e., a period following the release
> of 1.14.0 during which we'll still fix security bugs in 1.13.0?
Before I can offer an opinion on that, I have to ask: If that scenario
actually occurs, where a security issue is discovered in a release line
very soon after it goes EOL, does the fix have to be an actual *release*
with all the process that implies, or can it just be a (signed) patch?
Nathan
Re: Grace period for 1.13 users to upgrade to 1.14? (was: svn commit:
r1877222 - /subversion/site/publish/docs/release-notes/1.14.html)
Posted by Mark Phippard <ma...@gmail.com>.
On Fri, May 1, 2020 at 4:20 PM Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> Mark Phippard wrote on Fri, 01 May 2020 18:26 +00:00:
>
> > Since we reached the 6 month mark for 1.13 yesterday, that means its
> > support will continue until 1.14 is released at which point it is EOL.
>
> Can we dig down on this point a bit?
>
> On a macro scale, switching from "we support 1.9, 1.10, 1.13" to "we
> support 1.10, 1.14" is fine. No argument about that.
>
> However, once you dig down into the details, how are administrators of
> 1.13.x installations expected to upgrade to 1.14.x without running an
> unsupported version at any point?
>
> Presumably we don't expect 1.13.x users to run 1.14.0-rc2 in
> production — our RC announcement templates are quite clear about that —
> so I infer that we expect 1.13.x users to upgrade to 1.14.0 soon after
> its release.
>
> All I'm asking is that we quantify "soon".
>
> For example, if we say users of 1.13.x are expected to upgrade to 1.14.0
> within N days of the latter's release, that would mean that we promise not
> to do a 1.14.1 security release within those N days *unless* it's
> accompanied by a 1.13.1 release with a backport of the same fix.
>
> I'm not asking to set N to a large value. I'm just proposing that we
> document _some_ value, even if it's a small one, so users would know
> when to upgrade by.
>
I assume users upgrade when they have a reason to. Once 1.14 is released
our "policy" is that there will not be any additional 1.13 releases. Our
community always has the option of still creating a release if we feel it
is warranted and there is enough support for backporting/signing/RM the
release but we were clear what users should expect. There are already
several fixes in 1.14. If those are important to someone then they will
need to upgrade. If not, they can do it when they choose.
If users were concerned about our support then they could have stayed on
1.10 which still has 2 more years of support.
Mark
Re: Grace period for 1.13 users to upgrade to 1.14? (was: svn commit: r1877222 - /subversion/site/publish/docs/release-notes/1.14.html)
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Mark Phippard wrote on Fri, 01 May 2020 18:26 +00:00:
> On Fri, May 1, 2020 at 2:17 PM Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> > I'm not asking for special treatment or for changing the policy. I'm
> > asking to clarify the policy for the general case of the period of time
> > immediately following a 1.(x+1).0 release, where the 1.x line was a
> > non-LTS release. (In this specific instance x+1 is an LTS release, but
> > that's a red herring.)
>
> The way I read and understood the policy the support is time based. A
> regular release is supported for 6 months from its initial release date
> or until the next release is available. If the next release came out 5
> months later then it would still get 6 months of support. If the next
> release came out 9 months later then it would get 9 months of support.
>
Thanks for clarifying this. That's my understanding too.
> Since we reached the 6 month mark for 1.13 yesterday, that means its
> support will continue until 1.14 is released at which point it is EOL.
Can we dig down on this point a bit?
On a macro scale, switching from "we support 1.9, 1.10, 1.13" to "we
support 1.10, 1.14" is fine. No argument about that.
However, once you dig down into the details, how are administrators of
1.13.x installations expected to upgrade to 1.14.x without running an
unsupported version at any point?
Presumably we don't expect 1.13.x users to run 1.14.0-rc2 in
production — our RC announcement templates are quite clear about that —
so I infer that we expect 1.13.x users to upgrade to 1.14.0 soon after
its release.
All I'm asking is that we quantify "soon".
For example, if we say users of 1.13.x are expected to upgrade to 1.14.0
within N days of the latter's release, that would mean that we promise not
to do a 1.14.1 security release within those N days *unless* it's
accompanied by a 1.13.1 release with a backport of the same fix.
I'm not asking to set N to a large value. I'm just proposing that we
document _some_ value, even if it's a small one, so users would know
when to upgrade by.
Cheers,
Daniel
(And again, this has nothing to do with 1.14 being LTS. It's been an
issue since the first time a 6-month-support minor line was obsoleted
by a newer minor line.)
Re: Grace period for 1.13 users to upgrade to 1.14? (was: svn commit:
r1877222 - /subversion/site/publish/docs/release-notes/1.14.html)
Posted by Mark Phippard <ma...@gmail.com>.
On Fri, May 1, 2020 at 2:17 PM Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> Mark Phippard wrote on Fri, 01 May 2020 11:49 -0400:
> > On Thu, Apr 30, 2020 at 12:47 PM Daniel Shahaf <d....@daniel.shahaf.name>
> > wrote:
> >
> > > danielsh@apache.org wrote on Thu, 30 Apr 2020 16:21 -0000:
> > > > +++ subversion/site/publish/docs/release-notes/1.14.html Thu Apr 30
> > > 16:21:48 2020
> > > > @@ -1330,6 +1330,20 @@ if they occur.</p>
> > > > +<div class="h3" id="svn-1.13-deprecation">
> > > > +<h3>Subversion 1.13.x is end of life
> > > > + <a class="sectionlink" href="#svn-1.13-deprecation"
> > > > + title="Link to this section">¶</a>
> > > > +</h3>
> > > > +
> > > > +<p>The Subversion 1.13.x line is end of life (<abbr title="End Of
> > > Life">EOL</abbr>).
> > > > +This doesn't mean that your 1.13 installation is doomed; if it works
> > > > +well and is all you need, that's fine. "End of life" just means
> we've
> > > > +stopped accepting bug reports against 1.13.x versions, and will not
> > > > +make any more 1.13.x releases.</p>
> > >
> > > I just copied the text we use for 1.9, but there's a distinction: users
> > > of 1.9 have had time to upgrade to 1.10 before 1.14.0 becomes GA,
> > > whereas users of 1.13 have not. So, should we promise some sort of
> > > grace period for users of 1.13.x — i.e., a period following the release
> > > of 1.14.0 during which we'll still fix security bugs in 1.13.0?
> > >
> > > Granted, 1.13 was a regular release and was only promised to be
> > > supported for six months (or until 1.14.0) in the first place, so the
> > > grace period needn't be long.
> > >
> >
> > My recollection is that we gave 1.9 special treatment because 1.10 was
> the
> > first release with the new LTS policy in place. So we said we would
> handle
> > 1.9 the same way we would have prior to the new policy. I do not see any
> > reason to give 1.13 special treatment. We created the LTS policy and we
> > should plan on sticking to it. It is not like we do not have the option
> of
> > doing whatever we want when and if a security issue actually crops up.
>
> I'm not asking for special treatment or for changing the policy. I'm
> asking to clarify the policy for the general case of the period of time
> immediately following a 1.(x+1).0 release, where the 1.x line was a
> non-LTS release. (In this specific instance x+1 is an LTS release, but
> that's a red herring.)
>
The way I read and understood the policy the support is time based. A
regular release is supported for 6 months from its initial release date or
until the next release is available. If the next release came out 5 months
later then it would still get 6 months of support. If the next release
came out 9 months later then it would get 9 months of support.
Since we reached the 6 month mark for 1.13 yesterday, that means its
support will continue until 1.14 is released at which point it is EOL.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: Grace period for 1.13 users to upgrade to 1.14? (was: svn
commit: r1877222 - /subversion/site/publish/docs/release-notes/1.14.html)
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Mark Phippard wrote on Fri, 01 May 2020 11:49 -0400:
> On Thu, Apr 30, 2020 at 12:47 PM Daniel Shahaf <d....@daniel.shahaf.name>
> wrote:
>
> > danielsh@apache.org wrote on Thu, 30 Apr 2020 16:21 -0000:
> > > +++ subversion/site/publish/docs/release-notes/1.14.html Thu Apr 30
> > 16:21:48 2020
> > > @@ -1330,6 +1330,20 @@ if they occur.</p>
> > > +<div class="h3" id="svn-1.13-deprecation">
> > > +<h3>Subversion 1.13.x is end of life
> > > + <a class="sectionlink" href="#svn-1.13-deprecation"
> > > + title="Link to this section">¶</a>
> > > +</h3>
> > > +
> > > +<p>The Subversion 1.13.x line is end of life (<abbr title="End Of
> > Life">EOL</abbr>).
> > > +This doesn't mean that your 1.13 installation is doomed; if it works
> > > +well and is all you need, that's fine. "End of life" just means we've
> > > +stopped accepting bug reports against 1.13.x versions, and will not
> > > +make any more 1.13.x releases.</p>
> >
> > I just copied the text we use for 1.9, but there's a distinction: users
> > of 1.9 have had time to upgrade to 1.10 before 1.14.0 becomes GA,
> > whereas users of 1.13 have not. So, should we promise some sort of
> > grace period for users of 1.13.x — i.e., a period following the release
> > of 1.14.0 during which we'll still fix security bugs in 1.13.0?
> >
> > Granted, 1.13 was a regular release and was only promised to be
> > supported for six months (or until 1.14.0) in the first place, so the
> > grace period needn't be long.
> >
>
> My recollection is that we gave 1.9 special treatment because 1.10 was the
> first release with the new LTS policy in place. So we said we would handle
> 1.9 the same way we would have prior to the new policy. I do not see any
> reason to give 1.13 special treatment. We created the LTS policy and we
> should plan on sticking to it. It is not like we do not have the option of
> doing whatever we want when and if a security issue actually crops up.
I'm not asking for special treatment or for changing the policy. I'm
asking to clarify the policy for the general case of the period of time
immediately following a 1.(x+1).0 release, where the 1.x line was a
non-LTS release. (In this specific instance x+1 is an LTS release, but
that's a red herring.)
If we want to leave it as unspecified, I'll defer to consensus. And,
incidentally, I think we can likewise leave unspecified the policy for
which minor versions of Python 3 we'll support, thereby resolving
a (user-facing) TODO in the 1.14 release notes.
Cheers,
Daniel
Re: Grace period for 1.13 users to upgrade to 1.14? (was: svn commit:
r1877222 - /subversion/site/publish/docs/release-notes/1.14.html)
Posted by Mark Phippard <ma...@gmail.com>.
On Thu, Apr 30, 2020 at 12:47 PM Daniel Shahaf <d....@daniel.shahaf.name>
wrote:
> danielsh@apache.org wrote on Thu, 30 Apr 2020 16:21 -0000:
> > +++ subversion/site/publish/docs/release-notes/1.14.html Thu Apr 30
> 16:21:48 2020
> > @@ -1330,6 +1330,20 @@ if they occur.</p>
> > +<div class="h3" id="svn-1.13-deprecation">
> > +<h3>Subversion 1.13.x is end of life
> > + <a class="sectionlink" href="#svn-1.13-deprecation"
> > + title="Link to this section">¶</a>
> > +</h3>
> > +
> > +<p>The Subversion 1.13.x line is end of life (<abbr title="End Of
> Life">EOL</abbr>).
> > +This doesn't mean that your 1.13 installation is doomed; if it works
> > +well and is all you need, that's fine. "End of life" just means we've
> > +stopped accepting bug reports against 1.13.x versions, and will not
> > +make any more 1.13.x releases.</p>
>
> I just copied the text we use for 1.9, but there's a distinction: users
> of 1.9 have had time to upgrade to 1.10 before 1.14.0 becomes GA,
> whereas users of 1.13 have not. So, should we promise some sort of
> grace period for users of 1.13.x — i.e., a period following the release
> of 1.14.0 during which we'll still fix security bugs in 1.13.0?
>
> Granted, 1.13 was a regular release and was only promised to be
> supported for six months (or until 1.14.0) in the first place, so the
> grace period needn't be long.
>
My recollection is that we gave 1.9 special treatment because 1.10 was the
first release with the new LTS policy in place. So we said we would handle
1.9 the same way we would have prior to the new policy. I do not see any
reason to give 1.13 special treatment. We created the LTS policy and we
should plan on sticking to it. It is not like we do not have the option of
doing whatever we want when and if a security issue actually crops up.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: Grace period for 1.13 users to upgrade to 1.14? (was: svn commit:
r1877222 - /subversion/site/publish/docs/release-notes/1.14.html)
Posted by Mark Phippard <ma...@gmail.com>.
On Thu, Apr 30, 2020 at 12:47 PM Daniel Shahaf <d....@daniel.shahaf.name>
wrote:
> danielsh@apache.org wrote on Thu, 30 Apr 2020 16:21 -0000:
> > +++ subversion/site/publish/docs/release-notes/1.14.html Thu Apr 30
> 16:21:48 2020
> > @@ -1330,6 +1330,20 @@ if they occur.</p>
> > +<div class="h3" id="svn-1.13-deprecation">
> > +<h3>Subversion 1.13.x is end of life
> > + <a class="sectionlink" href="#svn-1.13-deprecation"
> > + title="Link to this section">¶</a>
> > +</h3>
> > +
> > +<p>The Subversion 1.13.x line is end of life (<abbr title="End Of
> Life">EOL</abbr>).
> > +This doesn't mean that your 1.13 installation is doomed; if it works
> > +well and is all you need, that's fine. "End of life" just means we've
> > +stopped accepting bug reports against 1.13.x versions, and will not
> > +make any more 1.13.x releases.</p>
>
> I just copied the text we use for 1.9, but there's a distinction: users
> of 1.9 have had time to upgrade to 1.10 before 1.14.0 becomes GA,
> whereas users of 1.13 have not. So, should we promise some sort of
> grace period for users of 1.13.x — i.e., a period following the release
> of 1.14.0 during which we'll still fix security bugs in 1.13.0?
>
> Granted, 1.13 was a regular release and was only promised to be
> supported for six months (or until 1.14.0) in the first place, so the
> grace period needn't be long.
>
My recollection is that we gave 1.9 special treatment because 1.10 was the
first release with the new LTS policy in place. So we said we would handle
1.9 the same way we would have prior to the new policy. I do not see any
reason to give 1.13 special treatment. We created the LTS policy and we
should plan on sticking to it. It is not like we do not have the option of
doing whatever we want when and if a security issue actually crops up.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/