Release 2.1

[phofl]

This is the tracker for the 2.1 release.

cc @pandas-dev/pandas-core

Targeted for August 3rd 2023

[phofl]

We released a new minor version every 6 months for the last couple of years. This is quite a long break between releases. I checked with @datapythonista and the amount of time that is required for a release was decreasing recently. I would be interested in releasing a new minor version more often to reduce the number of changes that are accumulating for a new release, which makes it harder to upgrade for our users. Also, getting improvements out faster is nice for us as well. I suggest releasing a new minor version every 4 months.

Thoughts about this?

[mroeschke]

Agreed we should shorten the release cadence for minor releases, especially if we aim to release major versions every year.

I would be okay with 4 months, even as frequent as 2 or 3 months dependence on the burden of the release process.

[jreback]

+1

[datapythonista]

Latest release (2.0.1) was very straight-forward, something that I think it's reasonable to do every other week for example. The main thing has been all the amazing work @lithomas1 did in automating the wheels, and also it made a significant difference tagging the evening before the release, so if nothing fails, everything is ready in the morning and in couple of hours the release is done. The main issues we had in the most recent releases will be now prevented by @mroeschke 's #53027, so I expect almost all releases to be as smooth as 2.0.1.

One thing we're not doing and I personally think it'd help is having more strict dates for the releases. For patch releases we're fine, and I think for major releases it's valuable to have flexibility and adapt the date to what we want to release. But if we want to release significantly more often, I'd personally set strict dates for the releases, and release what's ready on that date, instead of what we often do now to postpone one or two weeks the releases to try to get few more PRs in. Besides helping release more often, I think this would make things more predictable for both users and devs, and save us some time and energy when planning the releases. No big deal if people prefer to have the flexibility, but that's what I'd do.

[MarcoGorelli]

I'd be +1 releasing as often as is feasible. Right now there's too much of "we're finally going to release! Oh wait, it would be nice to get fix x in too, let's push it back another week". If people know there's going to be another release soon after, they don't need to rush to get their fixes in, and don't need to block releases for them.

Bi-weekly patch releases, bi-monthly minor releases, and yearly major releases, for example?

[phofl]

2 months is a bit too often maybe? Don't know. Could I ask for a preliminary show of hands for

• 2 months hooray emoji
• 3 months thumbs up
• 4 months heart emoji

Feel free to vote for more than one if you are happy with more than one solution

[simonjayhawkins]

Oh wait, it would be nice to get fix x in too, let's push it back another week". If people know there's going to be another release soon after, they don't need to rush to get their fixes in

I'm not sure this has applied to fixes for patch releases but for maybe more for outstanding items (maybe fixes) for enhancements in minor releases?

The patch releases have been mainly calendar releases without any significant holdups (except the final patch in the release cycle)

I'm -1 on too frequent releases unless we can ensure that we have no regressions outstanding in the minor release cycle. Even, with six months, delays to the final patch release in a minor release cycle are dependent on outstanding regressions.

Users should be able between minor versions without issue. i.e. if on pandas 1.3.5 should be able to upgrade to 1.4.4 without any regressions. If on 1.4.4 should be able to upgrade to 2.0.x. If a regression is identified, then should be able to report it and it should be fixed in the 2.0.x before 2.1 is released.

I think having very frequent minor releases may not make this feasible.

[phofl]

This is mostly because we either don't fix them at all or we can't fix them not because we run out of time. The regressions that we can address are mostly fixed within days of them getting reported.

[simonjayhawkins]

Other than developer timescales, we also need to consider user timescales. The user may decide to wait for the first or second patch release for stability and then identify an issue? I think 4 or 5 patch release gives a good window for regression fixes. Assuming more are identified early on, a patch release cycle of 3-3-4-5-6 weeks for the patches gives a 5 - 6 month minor release cycle.

[phofl]

We could also cut down to 3-3-3-3 and possibly another one after an additional 3 weeks and end up with 4 months.

Pushing less changes at a time should also reduce the number of regressions reported and lower the barrier of upgrading.

[simonjayhawkins]

sounds reasonable. Maybe could also consider keeping older branches active longer. i.e. releases aren't sequential, so a regression in 2.0.x could be fixed and backported even after 2.1 is released.

[simonjayhawkins]

We could also consider including all bug fixes in patch releases and having more of an enhancement focus on the minor releases and keep the minor release cycle to 6 months. This could also achieve the same goal?

[phofl]

I'd prefer shipping enhancements faster as well, but more importantly: Many, if not most, of our regressions are introduced through bug-fixes. I guess this would make patch releases a lot more unstable, which is kinda the opposite of what you'd prefer if I understood you correctly earlier?