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_at_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?
Received on 2020-02-14 14:06:02 CET