Julian's email reminded me I planned to reply to this one. On Mon, Oct 21, 2019 at 10:59 AM Stefan Sperling <s...@elego.de> wrote:
> On Mon, Oct 21, 2019 at 10:25:01AM -0400, Mark Phippard wrote: > > Yes. Go back to having new releases when there is enough interesting > > content to justify the release. We can lower the bar from the old days. > > There does not need to always be a big ticket feature or two driving the > > release, but if there is nothing worthy of a release we should not do one > > just because the calendar says so. > > I also had concerns in the beginning when Julian brought up the > proposal of time-based releases. I didn't expect it to work. > > But I think what Julian has shown us is that the calendar keeps us honest > in our commitment to actually do releases. If Julian hadn't been driving > this, I believe we would be in a situation where fixes would accumulate > on trunk and not be released at all, because a general lack of activity > makes doing releases look like a lot of work unless we're used to doing > them regularly and the process is streamlined accordingly. > > I have experience with time-based releases in another community (OpenBSD). > Releases happen every 6 months, like clock work. There's not much worry > about fixes and features missing the boat, because the next boat will be > prepared and ready soon enough. Avoiding the introduction of regressions > in new releases is a much bigger concern there, everything else can wait > when in doubt. > > I think this would also work well for Subversion, but we have to adopt a > mind set that makes this work. > I do not agree with this last statement (for the most part). Time-based releases are great. I wish we had pushed for this back when 1.4 landed. The difference is that OpenBSD and all of the other projects that follow this are active. We are not. I do not think this is about mindset, it is just facing the reality that there are not many changes happening. If OpenBSD only landed 2 bugfixes in a 6-month release cycle and the previous two releases were also pretty sparse, they might be having the same conversations. You raise a fair point that the clock does force some stuff. I am not sure the Python 3 work would have seen the same uptick if a release was not happening to stir things up again. I do not have any real objections if we want to continue to use time based releases and enough people are willing to put in the work to make that happen. I just do not think it is working and we ought to consider a new approach. I do not think the current 1.13 release is worth releasing. I think we should merge the Py 3 branch and release that as 1.13 once we think it is ready. That should essentially become the release we maintain until there is something new worth generating a new minor release, whenever that may be. -- Thanks Mark Phippard http://markphip.blogspot.com/
