Re: Subversion 1.10.0 end-of-life
Den fre 27 maj 2022 kl 16:34 skrev Daniel Shahaf : > Daniel Sahlberg wrote on Fri, 27 May 2022 10:40 +00:00: > > Den tors 26 maj 2022 kl 14:14 skrev Daniel Shahaf < > d...@daniel.shahaf.name>: > >> +0.5 to post to announce@ (and users@). Might want to post the full > >> draft here (including subject, etc.) first, though? > > > > I propose to reuse the news article, adding the tail from the release > > announcements. > > > > [[[ > > Subject: Apache Subversion 1.10.x end of life > > > > The Subversion 1.10.x line is end of life (EOL). It was released > 2018-04-13 > > and was supported for the last four years according to the LTS release > > life-cycle (see How we plan releases[1]). We recommend everyone to update > > to the current LTS release 1.14.2 as soon as practically possible since > > we've stopped accepting bug reports against 1.10.x and will not make any > > more 1.10.x releases. The last release (1.10.8) was made 2022-04-12 and > is > > available to anyone who can't update to 1.14. > > > > Looks good. > > Nits: > > - s/last release/last 1.10.x release/ > - s/ (2018|2022)/ on \1/ [two lines affected] > Thanks, r1901374. > Should we say something about 1.15? (I can argue either way.) > I would say something about 1.15 if we had a very strict timeline for the release. As of now, I don't think we have (sorry to say!). /Daniel
Re: Subversion 1.10.0 end-of-life
Daniel Sahlberg wrote on Fri, 27 May 2022 10:40 +00:00: > Den tors 26 maj 2022 kl 14:14 skrev Daniel Shahaf : >> +0.5 to post to announce@ (and users@). Might want to post the full >> draft here (including subject, etc.) first, though? > > I propose to reuse the news article, adding the tail from the release > announcements. > > [[[ > Subject: Apache Subversion 1.10.x end of life > > The Subversion 1.10.x line is end of life (EOL). It was released 2018-04-13 > and was supported for the last four years according to the LTS release > life-cycle (see How we plan releases[1]). We recommend everyone to update > to the current LTS release 1.14.2 as soon as practically possible since > we've stopped accepting bug reports against 1.10.x and will not make any > more 1.10.x releases. The last release (1.10.8) was made 2022-04-12 and is > available to anyone who can't update to 1.14. > Looks good. Nits: - s/last release/last 1.10.x release/ - s/ (2018|2022)/ on \1/ [two lines affected] Should we say something about 1.15? (I can argue either way.) Cheers, Daniel > Thanks, > - The Subversion Team > > [1] https://subversion.apache.org/roadmap.html#release-planning > > -- > To unsubscribe, please see: > > https://subversion.apache.org/mailing-lists.html#unsubscribing > ]]] > > > /Daniel
Re: Subversion 1.10.0 end-of-life
Den tors 26 maj 2022 kl 14:14 skrev Daniel Shahaf : > +0.5 to post to announce@ (and users@). Might want to post the full > draft here (including subject, etc.) first, though? I propose to reuse the news article, adding the tail from the release announcements. [[[ Subject: Apache Subversion 1.10.x end of life The Subversion 1.10.x line is end of life (EOL). It was released 2018-04-13 and was supported for the last four years according to the LTS release life-cycle (see How we plan releases[1]). We recommend everyone to update to the current LTS release 1.14.2 as soon as practically possible since we've stopped accepting bug reports against 1.10.x and will not make any more 1.10.x releases. The last release (1.10.8) was made 2022-04-12 and is available to anyone who can't update to 1.14. Thanks, - The Subversion Team [1] https://subversion.apache.org/roadmap.html#release-planning -- To unsubscribe, please see: https://subversion.apache.org/mailing-lists.html#unsubscribing ]]] /Daniel
Re: Subversion 1.10.0 end-of-life
Daniel Sahlberg wrote on Sun, 22 May 2022 21:07 +00:00: > Den mån 9 maj 2022 kl 14:12 skrev Nathan Hartman : > >> On Mon, May 9, 2022 at 7:38 AM Daniel Sahlberg < >> daniel.l.sahlb...@gmail.com> wrote: >> >>> Den sön 8 maj 2022 kl 02:21 skrev Daniel Shahaf : >>> Daniel Sahlberg wrote on Sat, 07 May 2022 18:37 +00:00: > Den lör 7 maj 2022 kl 14:17 skrev Daniel Shahaf < d...@daniel.shahaf.name>: > >> Daniel Sahlberg wrote on Sat, 07 May 2022 09:53 +00:00: >> > I've committed the changes in r1900649. >> >> I wonder if this merits a news entry on /index.html? Just "1.10.x is >> EOL; please upgrade to 1.14". >> > > Good point. I also considered this, but I couldn't find any other > release being announced EOL so I elected to not do this. I'm open > to reconsider! > Until today, most releases that have gone EOL did so either by virtue of a subsequent .0 release being made (1.0 through 1.8) or at about the same time as a subsequent .0 release being made (1.11 through 1.13 inclusive). In either case, at about the time of a release's going EOL there would have been a news entry (and announce@ post, and possibly a press release) about the new release, and the new release's release notes would have pointed out, at the very end, that previous releases were EOL'ed by the new release. So, to someone who knew our "support two release lines" policy, EOLings were very visible. >>> >>> Good point. I saw this in the release notes but I can't find anything in >>> announce@. Is the new release policy something we want to announce? >>> >>> I've added a news item in 1900735 et al. >>> >> >> >> I think we should announce it. >> >> The proposed news item looks good. >> >> One thing I might change is to suggest updating "as soon as practical," or >> something to that effect, and point out that 1.10.8, released last month, >> is available as a final 1.10 release. >> > > Thanks, sounds like a good idea. I've added this in r1901130. > > Can I just copy the news item text and post to announce@ +0.5 to post to announce@ (and users@). Might want to post the full draft here (including subject, etc.) first, though? > (I suppose I will have to configure my @apache.org address as sender). Yes. It's mail-relay.apache.org:587. Cheers, Daniel
Re: Subversion 1.10.0 end-of-life
Den mån 9 maj 2022 kl 14:12 skrev Nathan Hartman : > On Mon, May 9, 2022 at 7:38 AM Daniel Sahlberg < > daniel.l.sahlb...@gmail.com> wrote: > >> Den sön 8 maj 2022 kl 02:21 skrev Daniel Shahaf : >> >>> Daniel Sahlberg wrote on Sat, 07 May 2022 18:37 +00:00: >>> > Den lör 7 maj 2022 kl 14:17 skrev Daniel Shahaf < >>> d...@daniel.shahaf.name>: >>> > >>> >> Daniel Sahlberg wrote on Sat, 07 May 2022 09:53 +00:00: >>> >> > I've committed the changes in r1900649. >>> >> >>> >> I wonder if this merits a news entry on /index.html? Just "1.10.x is >>> >> EOL; please upgrade to 1.14". >>> >> >>> > >>> > Good point. I also considered this, but I couldn't find any other >>> release >>> > being announced EOL so I elected to not do this. I'm open to >>> reconsider! >>> > >>> >>> Until today, most releases that have gone EOL did so either by virtue of >>> a subsequent .0 release being made (1.0 through 1.8) or at about the >>> same time as a subsequent .0 release being made (1.11 through 1.13 >>> inclusive). In either case, at about the time of a release's going EOL >>> there would have been a news entry (and announce@ post, and possibly >>> a press release) about the new release, and the new release's release >>> notes would have pointed out, at the very end, that previous releases >>> were EOL'ed by the new release. So, to someone who knew our "support two >>> release lines" policy, EOLings were very visible. >>> >> >> Good point. I saw this in the release notes but I can't find anything in >> announce@. Is the new release policy something we want to announce? >> >> I've added a news item in 1900735 et al. >> > > > I think we should announce it. > > The proposed news item looks good. > > One thing I might change is to suggest updating "as soon as practical," or > something to that effect, and point out that 1.10.8, released last month, > is available as a final 1.10 release. > Thanks, sounds like a good idea. I've added this in r1901130. Can I just copy the news item text and post to announce@ (I suppose I will have to configure my @apache.org address as sender). /Daniel
Re: Subversion 1.10.0 end-of-life
On Mon, May 9, 2022 at 7:38 AM Daniel Sahlberg wrote: > Den sön 8 maj 2022 kl 02:21 skrev Daniel Shahaf : > >> Daniel Sahlberg wrote on Sat, 07 May 2022 18:37 +00:00: >> > Den lör 7 maj 2022 kl 14:17 skrev Daniel Shahaf > >: >> > >> >> Daniel Sahlberg wrote on Sat, 07 May 2022 09:53 +00:00: >> >> > I've committed the changes in r1900649. >> >> >> >> I wonder if this merits a news entry on /index.html? Just "1.10.x is >> >> EOL; please upgrade to 1.14". >> >> >> > >> > Good point. I also considered this, but I couldn't find any other >> release >> > being announced EOL so I elected to not do this. I'm open to reconsider! >> > >> >> Until today, most releases that have gone EOL did so either by virtue of >> a subsequent .0 release being made (1.0 through 1.8) or at about the >> same time as a subsequent .0 release being made (1.11 through 1.13 >> inclusive). In either case, at about the time of a release's going EOL >> there would have been a news entry (and announce@ post, and possibly >> a press release) about the new release, and the new release's release >> notes would have pointed out, at the very end, that previous releases >> were EOL'ed by the new release. So, to someone who knew our "support two >> release lines" policy, EOLings were very visible. >> > > Good point. I saw this in the release notes but I can't find anything in > announce@. Is the new release policy something we want to announce? > > I've added a news item in 1900735 et al. > I think we should announce it. The proposed news item looks good. One thing I might change is to suggest updating "as soon as practical," or something to that effect, and point out that 1.10.8, released last month, is available as a final 1.10 release. Cheers Nathan
Re: Subversion 1.10.0 end-of-life
Den sön 8 maj 2022 kl 02:21 skrev Daniel Shahaf : > Daniel Sahlberg wrote on Sat, 07 May 2022 18:37 +00:00: > > Den lör 7 maj 2022 kl 14:17 skrev Daniel Shahaf >: > > > >> Daniel Sahlberg wrote on Sat, 07 May 2022 09:53 +00:00: > >> > I've committed the changes in r1900649. > >> > >> I wonder if this merits a news entry on /index.html? Just "1.10.x is > >> EOL; please upgrade to 1.14". > >> > > > > Good point. I also considered this, but I couldn't find any other release > > being announced EOL so I elected to not do this. I'm open to reconsider! > > > > Until today, most releases that have gone EOL did so either by virtue of > a subsequent .0 release being made (1.0 through 1.8) or at about the > same time as a subsequent .0 release being made (1.11 through 1.13 > inclusive). In either case, at about the time of a release's going EOL > there would have been a news entry (and announce@ post, and possibly > a press release) about the new release, and the new release's release > notes would have pointed out, at the very end, that previous releases > were EOL'ed by the new release. So, to someone who knew our "support two > release lines" policy, EOLings were very visible. > Good point. I saw this in the release notes but I can't find anything in announce@. Is the new release policy something we want to announce? I've added a news item in 1900735 et al. Kind regards, Daniel
Re: Subversion 1.10.0 end-of-life
Daniel Sahlberg wrote on Sat, 07 May 2022 18:37 +00:00: > Den lör 7 maj 2022 kl 14:17 skrev Daniel Shahaf : > >> Daniel Sahlberg wrote on Sat, 07 May 2022 09:53 +00:00: >> > I've committed the changes in r1900649. >> >> I wonder if this merits a news entry on /index.html? Just "1.10.x is >> EOL; please upgrade to 1.14". >> > > Good point. I also considered this, but I couldn't find any other release > being announced EOL so I elected to not do this. I'm open to reconsider! > Until today, most releases that have gone EOL did so either by virtue of a subsequent .0 release being made (1.0 through 1.8) or at about the same time as a subsequent .0 release being made (1.11 through 1.13 inclusive). In either case, at about the time of a release's going EOL there would have been a news entry (and announce@ post, and possibly a press release) about the new release, and the new release's release notes would have pointed out, at the very end, that previous releases were EOL'ed by the new release. So, to someone who knew our "support two release lines" policy, EOLings were very visible. As to 1.9, I don't think we made a conscious decision _not_ to make a news entry pointing out that 1.9 went EOL, either. > There will be a bunch of further changes, for example the download page. > I'll commit to staging first and encourage review (it is getting late > here...) and will merge to publish later. Thanks for doing the legwork :) Daniel
Re: Subversion 1.10.0 end-of-life
Den lör 7 maj 2022 kl 14:17 skrev Daniel Shahaf : > Daniel Sahlberg wrote on Sat, 07 May 2022 09:53 +00:00: > > I've committed the changes in r1900649. > > I wonder if this merits a news entry on /index.html? Just "1.10.x is > EOL; please upgrade to 1.14". > Good point. I also considered this, but I couldn't find any other release being announced EOL so I elected to not do this. I'm open to reconsider! There will be a bunch of further changes, for example the download page. I'll commit to staging first and encourage review (it is getting late here...) and will merge to publish later. /Daniel
Re: Subversion 1.10.0 end-of-life
Den lör 7 maj 2022 kl 12:35 skrev Julian Foad : > Just to add my support: I am glad to see the community adapting the > release policy to suit the current circumstances. > Thanks Julian, it means a lot to have your support! /Daniel
Re: Subversion 1.10.0 end-of-life
Daniel Sahlberg wrote on Sat, 07 May 2022 09:53 +00:00: > I've committed the changes in r1900649. I wonder if this merits a news entry on /index.html? Just "1.10.x is EOL; please upgrade to 1.14".
Re: Subversion 1.10.0 end-of-life
Just to add my support: I am glad to see the community adapting the release policy to suit the current circumstances.
Re: Subversion 1.10.0 end-of-life
Den tors 5 maj 2022 kl 05:32 skrev Nathan Hartman : > On Wed, May 4, 2022 at 5:06 PM Daniel Sahlberg < > daniel.l.sahlb...@gmail.com> wrote: > >> This is a thread reply and not directly to Johan's e-mail, just grabbed >> the last one in the thread. >> >> I'm trying to sum up the thread with the hope that we can reach a >> decision within the next few days. >> >> In the thread there has been various +1's from Johan Corveleyn, Nathan >> Hartman, Daniel Shahaf and me. Stefan Sperling raised valuable points which >> I hope we have addressed (mainly not to have too many LTS releases at the >> same time: If we end up in a situation with frequent releases we should >> make new releases Regular instead of LTS). I have not seen anyone object to >> move away from time-based releases and I believe we are approaching >> consensus on this. >> >> Daniel Shahaf and I have co-authored some updates in >> staging: r1900404,r1900405,r1900528,r1900532,r1900561,r1900562. I have test >> merged these changes to publish and attach a patch showing the actual diff. >> > > > I've had a busy last few days and didn't respond here but I reviewed the > above commits soon after they were done as well as the page itself at > staging as it is now, and it looks good to me. > > There were a few minor things I was going to mention but they were fixed > before I got around to bringing them up. > > Thanks Daniel and Daniel for your work on this and thanks to everyone for > providing input. > > I think this release policy is a reasonable middle ground between the > original and the recent one, which is realistic and still keeps the most > important benefits of both. Hopefully everyone is happy with it. If you > have any input either way, please speak up!! > > > Regarding declaring 1.10 EOL, it was announced to have a 4 year support >> period /after/ it was released. I have seen no objections on applying this >> and assume we are approaching consensus on this as well. There will be a >> few additional changes (as noted by Danielsh elsewhere) to the website and >> to dist/release caused by the EOL. >> >> I will allow the thread a few days to soak to give everyone a last chance >> to raise concerns before making the actual commits. >> > > > Yes, let's wait and see for a few more days. > I've committed the changes in r1900649. Kind regards, Daniel >
Re: Subversion 1.10.0 end-of-life
On Wed, May 4, 2022 at 5:06 PM Daniel Sahlberg wrote: > This is a thread reply and not directly to Johan's e-mail, just grabbed > the last one in the thread. > > I'm trying to sum up the thread with the hope that we can reach a decision > within the next few days. > > In the thread there has been various +1's from Johan Corveleyn, Nathan > Hartman, Daniel Shahaf and me. Stefan Sperling raised valuable points which > I hope we have addressed (mainly not to have too many LTS releases at the > same time: If we end up in a situation with frequent releases we should > make new releases Regular instead of LTS). I have not seen anyone object to > move away from time-based releases and I believe we are approaching > consensus on this. > > Daniel Shahaf and I have co-authored some updates in > staging: r1900404,r1900405,r1900528,r1900532,r1900561,r1900562. I have test > merged these changes to publish and attach a patch showing the actual diff. > I've had a busy last few days and didn't respond here but I reviewed the above commits soon after they were done as well as the page itself at staging as it is now, and it looks good to me. There were a few minor things I was going to mention but they were fixed before I got around to bringing them up. Thanks Daniel and Daniel for your work on this and thanks to everyone for providing input. I think this release policy is a reasonable middle ground between the original and the recent one, which is realistic and still keeps the most important benefits of both. Hopefully everyone is happy with it. If you have any input either way, please speak up!! Regarding declaring 1.10 EOL, it was announced to have a 4 year support > period /after/ it was released. I have seen no objections on applying this > and assume we are approaching consensus on this as well. There will be a > few additional changes (as noted by Danielsh elsewhere) to the website and > to dist/release caused by the EOL. > > I will allow the thread a few days to soak to give everyone a last chance > to raise concerns before making the actual commits. > Yes, let's wait and see for a few more days. Cheers, Nathan
Re: Subversion 1.10.0 end-of-life
This is a thread reply and not directly to Johan's e-mail, just grabbed the last one in the thread. I'm trying to sum up the thread with the hope that we can reach a decision within the next few days. In the thread there has been various +1's from Johan Corveleyn, Nathan Hartman, Daniel Shahaf and me. Stefan Sperling raised valuable points which I hope we have addressed (mainly not to have too many LTS releases at the same time: If we end up in a situation with frequent releases we should make new releases Regular instead of LTS). I have not seen anyone object to move away from time-based releases and I believe we are approaching consensus on this. Daniel Shahaf and I have co-authored some updates in staging: r1900404,r1900405,r1900528,r1900532,r1900561,r1900562. I have test merged these changes to publish and attach a patch showing the actual diff. Regarding declaring 1.10 EOL, it was announced to have a 4 year support period /after/ it was released. I have seen no objections on applying this and assume we are approaching consensus on this as well. There will be a few additional changes (as noted by Danielsh elsewhere) to the website and to dist/release caused by the EOL. I will allow the thread a few days to soak to give everyone a last chance to raise concerns before making the actual commits. Kind regards, Daniel Sahlberg Index: docs/community-guide/releasing.part.html === --- docs/community-guide/releasing.part.html(revision 1900564) +++ docs/community-guide/releasing.part.html(working copy) @@ -1622,6 +1622,10 @@ Ask someone with appropriate access to add the A.B.x branch to the backport merge bot. + +Decide whether the release would be regular or LTS and record the +decision in lts_release_lines in tools/dist/release-lines.yaml +for release.py. Index: roadmap.html === --- roadmap.html(revision 1900564) +++ roadmap.html(working copy) @@ -86,41 +86,51 @@ title="Link to this section">¶ -Subversion plans to make a regular release every 6 months, - with a Long-Term Support (LTS) release every 2 years. - Regular releases are intended to deliver new features more quickly, while - LTS releases are intended to provide stability over longer periods. +Subversion has two types of releases: + regular releases are intended to deliver new features more quickly, while + LTS releases are intended to provide stability over longer periods. - - -type of release -emphasis -release every -support period -release numbers - - -LTS release -stability -2 years -4 years -1.10, 1.14, ... - - -regular release -features -6 months -6 months -1.11, 1.12, 1.13, ... - - +The two types releases differ in their support lifetime: + + +Regular releases are supported for six months from the date of +their initial release. For instance, 1.11.x was supported until six months +after the announcement of 1.11.0. A regular release may be used to get new +features out sooner without having to support a particular release for an +extended period of time, to make feature development more appealing, rewarding +and faster for both the contributors and the users. + +LTS releases are supported for four years from the date of their +initial release. For instance, 1.14.x will be supported until four years after +the announcement of 1.14.0. + +LTS releases are supported until three months after the release of +the next LTS. + +The previous two guarantees cumulate: for an LTS release line to be declared +end-of-life (EOL), it has to both have been first released over four +years before and have been supported in parallel to a newer LTS +release line for at least three months. + +For instance, assume 1.42.0 is released on 2042-07-01 and 1.42 is declared +an LTS line. In this case, 1.42 will be supported at least until 2046-06-30 +(with no ifs, buts, or maybes). Furthermore, it is expected that a newer LTS +release (1.43.0, 1.44.0, etc.) will be made before 2046-04-01, leaving three +months for upgrading installations. In case no newer LTS release is made +until, say, 2048-01-01, the lifetime of 1.42 will automatically be extended +until 2048-03-31. + +At any given time there will be at least one supported LTS release. The +most current LTS release will be supported with general backports and any +older release(s) will receive high priority fixes. + + + During the support period, we commit to providing updates that fix high priority issues such as security and data loss or corruption. We may also -sometimes fix other issues as appropriate to the emphasis of each release. -If a release takes longer than planned, we will extend the support periods -of the previous releases accordingly. +sometimes fix other issues as appropriate to the emphasis of each release.
Re: Subversion 1.10.0 end-of-life
On Thu, Apr 28, 2022 at 9:26 PM Nathan Hartman wrote: > On Thu, Apr 28, 2022 at 3:12 PM Stefan Sperling wrote: >> On Thu, Apr 28, 2022 at 01:29:43PM +, Daniel Shahaf wrote: >> > Stefan Sperling wrote on Thu, 28 Apr 2022 09:55 +00:00: >> > > I think it would be better to have such details spelled out in English >> > > in a manner that is easy to understand for anyone, with illustrating >> > > examples, instead of (or in addition to) mathematical notation that >> > > requires abstract thinking to figure out. >> > >> > I'm unable to interpret this charitably. >> >> Fine, I'll best just shut up then. > > Please, let's not have any of that!! Indeed! Stefan, I always appreciate your input / feedback / opinion / view on things, just as much as I appreciate Daniel's. So please keep it coming, both of you :-). I did not sense any sort of negative undertone or implicit criticism. Just useful feedback. At least that's my interpretation. Anyhow, moving on ... I agree with the direction this is heading, and +1 to Daniel's concrete patch that was posted a bit later (thanks for spelling things out). (But please, please, please ... keep input, feedback, ideas, chiming in, reservations, cheering, ... coming. Always.) -- Johan
Re: Subversion 1.10.0 end-of-life
Nathan Hartman wrote on Thu, Apr 28, 2022 at 15:25:55 -0400: > if we start releasing more frequent LTS .0 versions, we would end up > promising to support too many lines simultaneously. I hadn't > considered that because I was working from the assumption that we > aren't releasing new lines frequently enough for that to be a problem, > but we'd better document that in HACKING so the dev community doesn't > forget that in the future and create that situation. Maybe it'll be an > explanation about when to call a release LTS vs Regular. E.g., if > there exist two supported release lines then any further releases > should be Regular until the older LTS drops out. While there, HACKING should tell the RM to record the "Is it LTS or regular?" decision into release-lines.yaml:lts_release_lines.
Re: Subversion 1.10.0 end-of-life
Nathan Hartman wrote on Thu, Apr 28, 2022 at 15:25:55 -0400: > the explanation about support periods should be easy to understand. Index: staging/roadmap.html === --- staging/roadmap.html(revision 1900368) +++ staging/roadmap.html(working copy) @@ -86,41 +86,46 @@ title="Link to this section">¶ -Subversion plans to make a regular release every 6 months, - with a Long-Term Support (LTS) release every 2 years. - Regular releases are intended to deliver new features more quickly, while - LTS releases are intended to provide stability over longer periods. +Subversion has two types of releases: + regular releases are intended to deliver new features more quickly, while + LTS releases are intended to provide stability over longer periods. - - -type of release -emphasis -release every -support period -release numbers - - -LTS release -stability -2 years -4 years -1.10, 1.14, ... - - -regular release -features -6 months -6 months -1.11, 1.12, 1.13, ... - - +The two types releases differ in their support lifetime: + + +Regular releases are supported for six months from the date of +their initial release. For instance, 1.11.x was supported until six months +after the announcement of 1.11.0. + +LTS releases are supported for four years from the date of their +initial release. For instance, 1.15.x will supported until four years after +the announcement of 1.15.0. + +LTS releases are supported until three months after the release of +the the next LTS. + +The previous two guarantees cumulate: for an LTS release line to be declared +end-of-life (EOL), it has to both have been first released over four +years before and have been supported in parallel to a newer LTS +release line for at least three months. + +For instance, assume 1.42.0 is released on 2042-07-01 and 1.42 is declared +an LTS line. In this case, 1.42 will be supported at least until 2046-06-30 +(with no ifs, buts, or maybes). Furthermore, it is expected that a newer LTS +release (1.43.0, 1.44.0, etc.) will be made before 2046-04-01, leaving three +months for upgrading installations. In case no newer LTS release is made +until, say, 2048-01-01, the lifetime of 1.42 will automatically be extended +until 2048-03-31. + +At any given time there will be at least one supported LTS release. + + + During the support period, we commit to providing updates that fix high priority issues such as security and data loss or corruption. We may also -sometimes fix other issues as appropriate to the emphasis of each release. -If a release takes longer than planned, we will extend the support periods -of the previous releases accordingly. +sometimes fix other issues as appropriate to the emphasis of each release. In this context, "release" means an increment of the minor release number, which is the middle number in our three-component system. @@ -131,6 +136,9 @@ bugfixes have accumulated to warrant it. Major new releases, such as Subversion 2.0, will probably be done much like the minor releases, just with more planning around the exact features. + +To date, every release since 1.0 has been LTS, with the exception of 1.11, +1.12, and 1.13 which were regular. For more information about Subversion's release numbering and compatibility policies, see the section entitled
Re: Subversion 1.10.0 end-of-life
On Thu, Apr 28, 2022 at 3:25 PM Nathan Hartman wrote: > better document that in HACKING so the dev community doesn't forget that > in the future and create that situation. Maybe it'll be an explanation > about when to call a release LTS vs Regular. E.g., if there exist two > supported release lines then any further releases should be Regular until > the older LTS drops out. > Um, that was supposed to read: "E.g., if there exist two supported *LTS* release lines then any further releases should be Regular until the older LTS drops out." Cheers, Nathan
Re: Subversion 1.10.0 end-of-life
On Thu, Apr 28, 2022 at 3:12 PM Stefan Sperling wrote: > On Thu, Apr 28, 2022 at 01:29:43PM +, Daniel Shahaf wrote: > > Stefan Sperling wrote on Thu, 28 Apr 2022 09:55 +00:00: > > > I think it would be better to have such details spelled out in English > > > in a manner that is easy to understand for anyone, with illustrating > > > examples, instead of (or in addition to) mathematical notation that > > > requires abstract thinking to figure out. > > > > I'm unable to interpret this charitably. > > Fine, I'll best just shut up then. > Please, let's not have any of that!! You made a perfectly valid point that if we start releasing more frequent LTS .0 versions, we would end up promising to support too many lines simultaneously. I hadn't considered that because I was working from the assumption that we aren't releasing new lines frequently enough for that to be a problem, but we'd better document that in HACKING so the dev community doesn't forget that in the future and create that situation. Maybe it'll be an explanation about when to call a release LTS vs Regular. E.g., if there exist two supported release lines then any further releases should be Regular until the older LTS drops out. Also it's a valid point that the explanation about support periods should be easy to understand. Cheers, Nathan
Re: Subversion 1.10.0 end-of-life
On Thu, Apr 28, 2022 at 01:29:43PM +, Daniel Shahaf wrote: > Stefan Sperling wrote on Thu, 28 Apr 2022 09:55 +00:00: > > I think it would be better to have such details spelled out in English > > in a manner that is easy to understand for anyone, with illustrating > > examples, instead of (or in addition to) mathematical notation that > > requires abstract thinking to figure out. > > I'm unable to interpret this charitably. Fine, I'll best just shut up then.
Re: Subversion 1.10.0 end-of-life
Stefan Sperling wrote on Thu, 28 Apr 2022 09:55 +00:00: > I think it would be better to have such details spelled out in English > in a manner that is easy to understand for anyone, with illustrating > examples, instead of (or in addition to) mathematical notation that > requires abstract thinking to figure out. I'm unable to interpret this charitably. More below. > On Wed, Apr 27, 2022 at 11:43:02PM -0400, Nathan Hartman wrote: >> On Wed, Apr 27, 2022 at 4:56 PM Daniel Sahlberg >> wrote: >> > >> > Den ons 27 apr. 2022 kl 21:02 skrev Daniel Shahaf >> > : >> >> >> >> As to the general rule, I think we're missing a piece: the overlap >> >> period. We should say something along the lines of "Every LTS release >> >> will be supported for at least Y years, or until M months after the >> >> release of another LTS .0, whichever comes later.". >> > >> > >> > +1 to have an overlap period. >> > >> > Y = 4, M = 3? Or M = 6? >> >> I'm also +1 to have an overlap period, and the idea of "at least Y >> years, or until M months after the release of another LTS .0, >> whichever comes later" seems quite reasonable to me. > > Shouldn't this say "whichever comes earlier"? No. That would make Y meaningless: once 1.15.0 is release, admins won't be able to rely on any "Y years" promise since a 1.16.0 might be released sooner than M months before the Y years are up. That's basically the equivalent of telling someone "I'll babysit your kids on 2026-04-27 unless it's a sunny day". A promise with strings attached isn't. > Otherwise, the M months rule would never apply in case we release more > than one LTS line within Y years, right? Almost. It would never apply if we release two LTS .0's within $Y years - M months$ of each other. > Would we then end up fully supporting several lines of LTS releases? Yes. > Example with Y=4: > release 1.15.0 in year 1 (support 1.15) > release 1.16.0 in year 2 (support 1.15, 1.16) > release 1.17.0 in year 3 (support 1.15, 1.16, 1.17) > release 1.18.0 in year 4 (support 1.15, 1.16, 1.17, 1.18) > release 1.19.0 in year 5 (support 1.16, 1.17, 1.18, 1.19) > ... Books whose plots involve annual Apache Subversion releases go in the sci-fi section ;-) And if it becomes reality, we could make 1.16 a Regular release (as Nathan pointed out), or apply the "experimental" descriptor to new features more liberally. Daniel
Re: Subversion 1.10.0 end-of-life
On Wed, Apr 27, 2022 at 11:43:02PM -0400, Nathan Hartman wrote: > On Wed, Apr 27, 2022 at 4:56 PM Daniel Sahlberg > wrote: > > > > Den ons 27 apr. 2022 kl 21:02 skrev Daniel Shahaf : > >> > >> As to the general rule, I think we're missing a piece: the overlap > >> period. We should say something along the lines of "Every LTS release > >> will be supported for at least Y years, or until M months after the > >> release of another LTS .0, whichever comes later.". > > > > > > +1 to have an overlap period. > > > > Y = 4, M = 3? Or M = 6? > > > I'm also +1 to have an overlap period, and the idea of "at least Y > years, or until M months after the release of another LTS .0, > whichever comes later" seems quite reasonable to me. Shouldn't this say "whichever comes earlier"? Otherwise, the M months rule would never apply in case we release more than one LTS line within Y years, right? Would we then end up fully supporting several lines of LTS releases? Example with Y=4: release 1.15.0 in year 1 (support 1.15) release 1.16.0 in year 2 (support 1.15, 1.16) release 1.17.0 in year 3 (support 1.15, 1.16, 1.17) release 1.18.0 in year 4 (support 1.15, 1.16, 1.17, 1.18) release 1.19.0 in year 5 (support 1.16, 1.17, 1.18, 1.19) ... I think it would be better to have such details spelled out in English in a manner that is easy to understand for anyone, with illustrating examples, instead of (or in addition to) mathematical notation that requires abstract thinking to figure out.
Re: Subversion 1.10.0 end-of-life
On Wed, Apr 27, 2022 at 4:56 PM Daniel Sahlberg wrote: > > Den ons 27 apr. 2022 kl 21:02 skrev Daniel Shahaf : >> >> As to the general rule, I think we're missing a piece: the overlap >> period. We should say something along the lines of "Every LTS release >> will be supported for at least Y years, or until M months after the >> release of another LTS .0, whichever comes later.". > > > +1 to have an overlap period. > > Y = 4, M = 3? Or M = 6? I'm also +1 to have an overlap period, and the idea of "at least Y years, or until M months after the release of another LTS .0, whichever comes later" seems quite reasonable to me. Cheers, Nathan
Re: Subversion 1.10.0 end-of-life
Den ons 27 apr. 2022 kl 21:02 skrev Daniel Shahaf : > Nathan Hartman wrote on Tue, 26 Apr 2022 13:58 +00:00: > > On Tue, Apr 26, 2022 at 5:57 AM Stefan Sperling wrote: > >> > >> On Mon, Apr 25, 2022 at 10:05:58PM +0200, Daniel Sahlberg wrote: > >> > Hi, > >> > > >> > According to the Roadmap, How we plan releases[1], 1.10.0 is a LTS > release > >> > that will receive support for 4 years. According to the News > archive[2], > >> > 1.10.0 was released 2018-04-13. > >> > > >> > 1.10.0 was released approximately two months before the transition to > the > >> > LTS support policy and I have not been able to dig out what was > promised > >> > previously. > >> > >> Before LTS releases, the 2 most recent lines of releases were supported. > >> The most recent one would receive all types of bug fixes, the second one > >> would receive security or data-corruption fixes only. > ⋮ > >> Going back to the old policy would mean that 1.10 would be supported > >> until 1.15 comes out. At which point only 1.15 and 1.14 would be > supported. > > > > > > The older policy seems simpler. > > > > One good takeaway from the new policy is that we give the expected > > lifespan of a release line to help admins plan server upgrades. It > > also helps us with our own planning. [...] For reasons like this, > declaring > > the expected lifespan as we've been doing since the new policy is > > helpful. > > +1 > I'm also +1 on declaring an expected life span. > We could keep the LTS vs Regular distinction because it standardizes > > on two possible lifespans, either 4 years or 6 months, BUT stop > > promising to make Regular releases, neither at 6 months nor any other > > frequency. It becomes optional to make a Regular release if and when > > it makes sense and the developers and community are willing and able > > make it happen. > > +1 > Also +1. At the current release pace we should try to make every release an LTS, but if we would make releases more often in the future then we could declare some of them "Regular". > > > Back to Daniel's question: Since we aren't currently making a new LTS > > release every 2 years, I think it makes sense to go with what Stefan > > suggests, meaning EOL 1.10.x when 1.15.0 is released. > > > > We actually already document (in > https://subversion.apache.org/roadmap.html#release-planning, which is > linked from the download page) that 1.9 and 1.10 will be LTS with the > four-year lifetime. Assuming we wrote that part _before_ we released > 1.10.0, that means 1.10 is EOL now and we can mark it as such. > That part was written two months after 1.10 was released according to the log of roadmap.html. > At this time, we might warn that 1.10.x is "deprecated" (or something > > along those lines) by which I mean to warn users that 1.10.x will be > > EOL when the next minor release is made and encourage upgrading to > > 1.14.x as soon as reasonable. This means we could still make 1.10.x > > patch releases if it makes sense to do so, but admins should not > > count on that support continuing for any definable length of time. > If we decide that we should give 1.10 an extended life, I agree it should be "deprecated" and we should only backport things that are really REQUIRED (security and data corruption issues). > > > > I know that seems kind of ad-hoc. It would be very helpful if we could > > as a community decide this policy question and then update the site. > > As to the general rule, I think we're missing a piece: the overlap > period. We should say something along the lines of "Every LTS release > will be supported for at least Y years, or until M months after the > release of another LTS .0, whichever comes later.". > +1 to have an overlap period. Y = 4, M = 3? Or M = 6? But maybe we can be even stricter with only fixing security and data corruption issues during M. But the general principle of having only one supported LTS at this point > in time, since 1.10 has EOL'd, seems sound to me. We have fewer hands > on deck nowadays, so we should try to support fewer lines. > /Daniel [1] https://subversion.apache.org/roadmap.html#release-planning
Re: Subversion 1.10.0 end-of-life
Nathan Hartman wrote on Tue, 26 Apr 2022 13:58 +00:00: > On Tue, Apr 26, 2022 at 5:57 AM Stefan Sperling wrote: >> >> On Mon, Apr 25, 2022 at 10:05:58PM +0200, Daniel Sahlberg wrote: >> > Hi, >> > >> > According to the Roadmap, How we plan releases[1], 1.10.0 is a LTS release >> > that will receive support for 4 years. According to the News archive[2], >> > 1.10.0 was released 2018-04-13. >> > >> > 1.10.0 was released approximately two months before the transition to the >> > LTS support policy and I have not been able to dig out what was promised >> > previously. >> >> Before LTS releases, the 2 most recent lines of releases were supported. >> The most recent one would receive all types of bug fixes, the second one >> would receive security or data-corruption fixes only. ⋮ >> Going back to the old policy would mean that 1.10 would be supported >> until 1.15 comes out. At which point only 1.15 and 1.14 would be supported. > > > The older policy seems simpler. > > One good takeaway from the new policy is that we give the expected > lifespan of a release line to help admins plan server upgrades. It > also helps us with our own planning. [...] For reasons like this, declaring > the expected lifespan as we've been doing since the new policy is > helpful. +1 > We could keep the LTS vs Regular distinction because it standardizes > on two possible lifespans, either 4 years or 6 months, BUT stop > promising to make Regular releases, neither at 6 months nor any other > frequency. It becomes optional to make a Regular release if and when > it makes sense and the developers and community are willing and able > make it happen. +1 > Back to Daniel's question: Since we aren't currently making a new LTS > release every 2 years, I think it makes sense to go with what Stefan > suggests, meaning EOL 1.10.x when 1.15.0 is released. > We actually already document (in https://subversion.apache.org/roadmap.html#release-planning, which is linked from the download page) that 1.9 and 1.10 will be LTS with the four-year lifetime. Assuming we wrote that part _before_ we released 1.10.0, that means 1.10 is EOL now and we can mark it as such. > At this time, we might warn that 1.10.x is "deprecated" (or something > along those lines) by which I mean to warn users that 1.10.x will be > EOL when the next minor release is made and encourage upgrading to > 1.14.x as soon as reasonable. This means we could still make 1.10.x > patch releases if it makes sense to do so, but admins should not > count on that support continuing for any definable length of time. > > I know that seems kind of ad-hoc. It would be very helpful if we could > as a community decide this policy question and then update the site. As to the general rule, I think we're missing a piece: the overlap period. We should say something along the lines of "Every LTS release will be supported for at least Y years, or until M months after the release of another LTS .0, whichever comes later.". But the general principle of having only one supported LTS at this point in time, since 1.10 has EOL'd, seems sound to me. We have fewer hands on deck nowadays, so we should try to support fewer lines. Cheers, Daniel
Re: Subversion 1.10.0 end-of-life
On Tue, Apr 26, 2022 at 5:57 AM Stefan Sperling wrote: > > On Mon, Apr 25, 2022 at 10:05:58PM +0200, Daniel Sahlberg wrote: > > Hi, > > > > According to the Roadmap, How we plan releases[1], 1.10.0 is a LTS release > > that will receive support for 4 years. According to the News archive[2], > > 1.10.0 was released 2018-04-13. > > > > 1.10.0 was released approximately two months before the transition to the > > LTS support policy and I have not been able to dig out what was promised > > previously. > > Before LTS releases, the 2 most recent lines of releases were supported. > The most recent one would receive all types of bug fixes, the second one > would receive security or data-corruption fixes only. > > I think it would make sense to go back to our old release policy. > > As far as I understand, the goal of the LTS policy was to publish > releases more quickly to get features tested earlier by users and > gather feedback before such features would be set in stone as part > of an LTS release. This policy was invented at the same time as the > shelving feature. I don't know for sure but I believe this feature and > the involvement of a particular sponsor with some time-to-market constraints > are part of the reason why a release policy change was suggested in the first > place. The shelving feature was developed in multiple iterations and was > shipped in several drafts, as planned. But it never made it beyond an > experimental status, and given there has not been further development effort > on this feature for quite some time I don't believe this will change. > No other feature I am aware of has since adopted the development and > release model which was introduced along with the shelving feature. > > The old release policy had its own share of problems. Essentially, > every release was an LTS release, but the support time window for a > release was not announced in advance. In practice, due to relatively slow > pace of development, it worked out well (just look at the pacing of past > release in the CHANGES file, it was not unreasonable). > The most significant drawback of the old policy at the time was that the > incentive to ship a release with features in early stages of development > was very low. It was difficult to decide when the code on trunk was ready > to be released. Every released feature had to be supported with full > backwards compatibility going forward. > This caused some friction, again with sponsors who had time-to-market > constraints. The most prominent case occurred in the 1.5 cycle during > which merge-tracking was developed (see here for an essay about this: > http://www.hyrumwright.org/papers/floss2009.pdf). Ultimately, merge-tracking > was shipped in a de-facto "experimental" state, and users were not all happy > about this. Later releases had to correct several design-level problems and > implementation bugs. Had the current LTS/non-LTS release split existed at > that time, some of these issues might have been avoided before appearing > as part of an LTS release and be supported forever. > > In any case, our current policy only works when it is actually implemented > as intended, and this is not happening. In my opinion, our old release policy > is more suited for the current state of things. Feature development does not > need to be rushed, we don't have sponsors anymore who promise features to > their clients and then come back to the project to ask about our progress > on the next release. And our userbase seems to be more interested in a > stable long-term support platform than in trying out experimental features. > > Going back to the old policy would mean that 1.10 would be supported > until 1.15 comes out. At which point only 1.15 and 1.14 would be supported. > > Cheers, > Stefan The older policy seems simpler. One good takeaway from the new policy is that we give the expected lifespan of a release line to help admins plan server upgrades. It also helps us with our own planning. For example, at the time 1.14.x was released, Python 2 was still supported, but because we knew the expected lifespan of 1.14.x of 4 years would extend well after Python 2 went EOL, we were able to warn users, through our Release Notes, that while we would "try" to keep supporting Python 2 through the life of 1.14.x, we couldn't promise that and might have to drop that support if it became too burdensome. For reasons like this, declaring the expected lifespan as we've been doing since the new policy is helpful. We could keep the LTS vs Regular distinction because it standardizes on two possible lifespans, either 4 years or 6 months, BUT stop promising to make Regular releases, neither at 6 months nor any other frequency. It becomes optional to make a Regular release if and when it makes sense and the developers and community are willing and able make it happen. Regarding sponsors who would like to get features developed and released quickly, I think we should encourage it; at the same time
Re: Subversion 1.10.0 end-of-life
On Mon, Apr 25, 2022 at 10:05:58PM +0200, Daniel Sahlberg wrote: > Hi, > > According to the Roadmap, How we plan releases[1], 1.10.0 is a LTS release > that will receive support for 4 years. According to the News archive[2], > 1.10.0 was released 2018-04-13. > > 1.10.0 was released approximately two months before the transition to the > LTS support policy and I have not been able to dig out what was promised > previously. Before LTS releases, the 2 most recent lines of releases were supported. The most recent one would receive all types of bug fixes, the second one would receive security or data-corruption fixes only. I think it would make sense to go back to our old release policy. As far as I understand, the goal of the LTS policy was to publish releases more quickly to get features tested earlier by users and gather feedback before such features would be set in stone as part of an LTS release. This policy was invented at the same time as the shelving feature. I don't know for sure but I believe this feature and the involvement of a particular sponsor with some time-to-market constraints are part of the reason why a release policy change was suggested in the first place. The shelving feature was developed in multiple iterations and was shipped in several drafts, as planned. But it never made it beyond an experimental status, and given there has not been further development effort on this feature for quite some time I don't believe this will change. No other feature I am aware of has since adopted the development and release model which was introduced along with the shelving feature. The old release policy had its own share of problems. Essentially, every release was an LTS release, but the support time window for a release was not announced in advance. In practice, due to relatively slow pace of development, it worked out well (just look at the pacing of past release in the CHANGES file, it was not unreasonable). The most significant drawback of the old policy at the time was that the incentive to ship a release with features in early stages of development was very low. It was difficult to decide when the code on trunk was ready to be released. Every released feature had to be supported with full backwards compatibility going forward. This caused some friction, again with sponsors who had time-to-market constraints. The most prominent case occurred in the 1.5 cycle during which merge-tracking was developed (see here for an essay about this: http://www.hyrumwright.org/papers/floss2009.pdf). Ultimately, merge-tracking was shipped in a de-facto "experimental" state, and users were not all happy about this. Later releases had to correct several design-level problems and implementation bugs. Had the current LTS/non-LTS release split existed at that time, some of these issues might have been avoided before appearing as part of an LTS release and be supported forever. In any case, our current policy only works when it is actually implemented as intended, and this is not happening. In my opinion, our old release policy is more suited for the current state of things. Feature development does not need to be rushed, we don't have sponsors anymore who promise features to their clients and then come back to the project to ask about our progress on the next release. And our userbase seems to be more interested in a stable long-term support platform than in trying out experimental features. Going back to the old policy would mean that 1.10 would be supported until 1.15 comes out. At which point only 1.15 and 1.14 would be supported. Cheers, Stefan
