Johan Corveleyn wrote:
Nathan Hartman wrote:
    Branko Čibej  wrote:
     > By the principle of least surprise, I think it
     > would be better to merge to trunk, create a
     > new 1.13.0 release candidate

    +1

     > and (maybe?) restart the soak.

    I support this idea even if the soak must restart or be extended.

+1. Since 1.13 contains so very little, I think it's good to be a bit flexible with our planned timing here, to get this on board. I.e. let's merge it in, cut a new rc, and restart the soak.

Dear all, with respect,

I would love to see the Py3 support released ASAP.

But, have we not learned from our past mistakes? We have prepared a regular release that is right now looking to be ready to deploy next week, on time. If we postpone and destabilize it now [1], this would make mockery of "regular" releases. I would love to trust that merging the branch will go smoothly with no follow-up required and no extra time taken, but history has taught us that it is foolish to assume so.

Surely the right approach is to release what we have got (the currently soaking 1.13), then release the new one as soon as we can get it ready. It sounds like it's not suitable for a patch release, so we'll make it a new minor release, calling it 1.14.

Nothing says we shouldn't release an extra minor release, or that we shouldn't make two minor releases close together.

Sure, there are no major developments in 1.13, but there are important fixes [2]. And sure, 1.14 was previously listed as expected to be the next LTS, and now it won't be. And people will need to choose whether to upgrade to both or just one of them. And we will have to adjust our terminology and docs a little as we will be calling it neither "regular" nor "LTS". All small things to sort out. No big deal.

Then we will achieve everything we wanted. The regular releases remain regular. The new stuff gets released ASAP, and before the next LTS release.

The existing 1.13 release has value in itself. In the role of release manager, I plan to go ahead with the 1.13 release, and I would urge you to support this by helping provide the final tests and signatures. Then I will be willing to roll another release, including all the web site updates etc, as soon as we can get it ready.

Can we do it that way, please?

- Julian


[1] Yes, from a release manager's POV, this is destabilizing, no matter how much it has been tested already.

[2] There are important fixes in 1.13 that, if 1.13 were not to be available, should otherwise be backported and released in 1.12. We are not releasing them in a 1.12 patch because 1.13 is "known" to be coming soon.

Reply via email to