On Fri, Feb 14, 2020 at 07:36:43AM -0500, Nathan Hartman wrote: > On Fri, Feb 14, 2020 at 7:26 AM Stefan Sperling <s...@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?
