subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Sperling <s...@elego.de>
Subject Re: Release Management, Subversion 1.14
Date Fri, 14 Feb 2020 13:05:50 GMT
On Fri, Feb 14, 2020 at 07:36:43AM -0500, Nathan Hartman wrote:
> On Fri, Feb 14, 2020 at 7:26 AM Stefan Sperling <stsp@elego.de> wrote:
> 
> > - Release notes and CHANGES need to be updated.
> >   There are relatively few changes since we only have to document what
> >   changed since September. I am wondering if 1.14 release note should
> >   summarize what occurred betwen 1.10 and 1.14, or if they should be
> >   written relative to 1.13 as the current draft implies.
> >   For users upgrading from LTS to LTS it might make sense to give an
> >   overview of what changed on one page. And it would also give us more
> >   material to fill the release notes page with :)
> >
> 
> I was thinking about this a few days ago. I think that LTS releases are a
> different "line" and the release notes should include changes since 1.10.
> If the community agrees with that, I'll work on it.

In my opinion that would be great. Thanks!

> More below...
> 
> - We need to decide what happens after 1.14. It would make sense to have a
> >   new plan agreed upon. If we don't decide on anything we'll end up with a
> >   1.15 release planned for October 2020. I doubt this plan is still viable
> >   given how little is happening right now in order to prepare 1.14.
> >
> I think that the minor version number should not be incremented unless
> there are new features. If only bug fixes are available, the policy should
> be to backport them to the maintained releases and release a new point
> version every 6 months. So 1.14.x could be the latest version for some
> time, but we'll continue to have a regular release schedule.

Having a fixed schedule for releasing any non-critical fixes which have
accumulated would be good to avoid letting such fixes sit in our repository
for too long. On the other hand, following a regular release schedule too
strictly would be too restrictive since we may need the ability to release 
security or data corruption fixes more quickly.

And I like the time-based approach but the currently planned feature
release frequency doesn't match our actual pace of development.

I guess we could plan to issue new 1.10.x and 1.14.x releases every 6 months,
with any critical fixes (security or data corruption) getting released as soon
as possible. 1.15 would happen only if new APIs must be introduced to fix a
problem, or if new APIs have been introduced with new features added within
the previous 6 months cycle. Until 1.15 happens we support 1.10 and 1.14.
Once 1.15 appears, we support 1.14 and 1.15 until 1.16 appears, and so on.

Would this work?

Mime
View raw message