Release 2.1 #53047
Comments
|
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? |
|
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. |
|
+1 |
|
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. |
|
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? |
|
2 months is a bit too often maybe? Don't know. Could I ask for a preliminary show of hands for
Feel free to vote for more than one if you are happy with more than one solution |
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. |
|
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. |
|
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. |
|
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. |
|
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. |
|
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? |
|
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? |
We should probably do some analysis for this as it could be that refactors and clean-ups account for a few.
yes, I acknowledge there is increased risk with this. |
The upside is that it may become easier to revert these before too many changes have been built on top of them as has been the case with the bugfixes being included in the minor releases. |
|
Personally (from a user pov), I'd prefer stable patches and shorter release cycles, I want to get the newest patch without having to worry about stuff breaking while switching to a new minor version requires some attention anyway. Our ci was always running with the newest patch and we barely had issues (ever) but we made a conscious effort when switching to a new minor version. |
+1 on this as well. Users should feel quite safe upgrading the patch version, and I worry about the regressions that can be induced by bug fixes. The longer a commit sits in main before being release, the greater the chances an issue is discovered without being released, but the longer users have to wait for improvements and the changes are more numerous. 3 months sounds like a good sweet spot, but I'm also okay with 2 or 4 months. |
Agreed. I would suggest that if we did include more bug fixes in patch releases (although not much support so far) that any regression reported on a patch triggers an immediate revert and re-release. I see this as potentially more effort but does get bug fixes out into the community much quicker than increasing the minor release frequency. |
|
One thing that I want to point out is that for minor/major releases, we cut an RC (about 2 weeks before, IIRC). Assuming we want to keep the RCs at least semi-close to the release (I believe we don't do new API changes, have minimal new enhancements, but allow bug fixes), 2/3 months might be too short of a window to get larger new features in. |
|
During the 2023-07-26 dev call, agreed to cut the RC during the dev sprint |
|
As the RC gets closer, I've thought of some potential blockers/issues off the top of my head.
Anyone want to add anything else? @pandas-dev/pandas-core I'm also thinking about cancelling the 2.0.4 release. Nothing has been merged for 2.0.4 as of right now, so just giving a heads up in case anyone has any last minute regressions they want to address. |
|
@pandas-dev/pandas-core Hi all, We currently have 2 blockers (https://github.com/pandas-dev/pandas/issues?q=is%3Aissue+is%3Aopen+label%3ABlocker) Are there any thoughts/comments/objections on the release timing, or any other potential blockers I've missed? |
|
The stuff that's related to the string option should get in. I'd prefer next Monday for the release, but if that's not doable the lets push it back as far as you can before your vacation |
No problem (and no rush on your PRs). I actually have to go back to school not vacation, though. :( |
Looks like these are both in now |
|
I would like to include #54838, since it changes some public signatures for downstream EA authors, in case someone could give it a review |
|
PRs seem to be all in now |
|
Awesome @pandas-dev/pandas-core I'm planning on starting the release ~7am eastern (11 UTC) and finishing around ~11AM eastern (3pm utc) |
|
Starting the release right now.
|
|
So the ppc64le and some PyPy builds ended up failing. I don't really have the ability to debug this (they were passing on the RC), so maybe we can just announce and add those later if they do end up succeeding? Downloading the ppc wheels, everything inside looks fine (there is an import error like the Not sure about the PyPy errors, they only appeared after I merged the PR into main for some reason. |
|
The PyPy errors are from PyPy 7.3.12 from a couple days ago. |
This is the tracker for the 2.1 release.
cc @pandas-dev/pandas-core
Targeted for August 3rd 2023
The text was updated successfully, but these errors were encountered: