Julian's email reminded me I planned to reply to this one.
On Mon, Oct 21, 2019 at 10:59 AM Stefan Sperling <stsp_at_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/
Received on 2019-10-22 16:13:27 CEST