On Mon, Aug 5, 2019 at 10:46 AM Mike Miller <[email protected]> wrote: > > What happens if nobody is interested in being a release manager for a > version? > What happens if the schedule is missed? > - Then there is no release. I would imagine if we can find the right time > frame and devs are actively working, this won't be a problem though. > Perhaps simplifying the release process would help ease the burden of > releasing.
Release schedule and LTS are two separate issues. We could adopt the concept of having LTS releases w/o having a fixed schedule. I think there are benefits to clearly communicating if a release will be bug fixed or not. > > Who handles reminders for scheduling new releases? > - We can post the schedule. Reminders are optional, if someone wants to > notify the community they can. > > Will we establish freeze deadlines for features? > How do we enforce freezes in the C-T-R model? > - I think that is a good idea. We could do an API freeze further out, say > like 3 months. Then a full freeze a week before. A tag could be created > to freeze the code. > > What if there's nothing compelling a release when a scheduled release > is approaching? > What happens if a scheduled release is approaching, but the community > is focused on critical patches for a previous release? > - Same as my first comment. I also think "compelling" is difficult to > define, so we shouldn't worry about that. A single bug fix could be > compelling to someone. I think its different for everyone. Even a LTS > release that is 100% bug fixes with no new features could be compelling to > a team who is resistant to upgrading. > > On Fri, Aug 2, 2019 at 2:35 PM Christopher <[email protected]> wrote: > > > I'm in favor of this generally, but worry a bit about making release > > schedule guarantees, due to the volunteer nature of the project Apache > > projects in general. > > > > What happens if nobody is interested in being a release manager for a > > version? > > What happens if the schedule is missed? > > Who handles reminders for scheduling new releases? > > Will we establish freeze deadlines for features? > > How do we enforce freezes in the C-T-R model? > > What if there's nothing compelling a release when a scheduled release > > is approaching? > > What happens if a scheduled release is approaching, but the community > > is focused on critical patches for a previous release? > > > > On Fri, Aug 2, 2019 at 12:43 PM Keith Turner <[email protected]> wrote: > > > > > > I am in favor of this. One possible way to move this forward would be > > > to write the following two proposals. > > > > > > * Transition proposal : lays out how we will transition to this > > > plan. For example it could outline that 1.9 will become the first > > > LTS. > > > * Release schedule proposal : lays out how the Accumulo release > > > schedule would work. > > > > > > The proposals could be made as website PRs and discussion could happen > > > on the PR. If the proposals are adopted by the community, then they > > > could be turned into documentation. > > > > > > On Fri, Aug 2, 2019 at 12:08 PM Mike Miller <[email protected]> wrote: > > > > > > > > I think it would be good for Accumulo to adopt a Long Term Support > > (LTS) > > > > type release schedule. It seems to work well for other projects like > > > > Ubuntu and now Java is doing the same. We could have 2 branches of LTS > > > > versions, similar to what we have now with 1.9 and 2.0. Then set a > > > > schedule, say every 6 months or a year, release a minor/major > > version. For > > > > example: > > > > > > > > 1.9.0 LTS released April 2018 > > > > 2.0.0 LTS released August 2019 > > > > 1.10.0 LTS scheduled to release April 2020 > > > > 2.x.0 LTS scheduled to release August 2021 > > > > > > > > Bug fixes for the versions can be released as needed. We can even > > release > > > > minor versions, like 2.1.0 just as a tag, and then merge into the main > > 2.x > > > > branch. That way we only ever have to deal with 2 branches. The > > > > motivation for this is to not have so much time (and so many changes) > > > > between releases like we did for 2.0. This would also help users with > > > > scheduling upgrades. > >
