Plans for pandas 0.25.0 and pandas 1.0
Hi all, We had some discussion about this on the in-person dev sprint end of June, and I thought it would be good to have some public record of this as well. A pandas 0.25.0 release is close (the RC was released earlier this month), see https://github.com/pandas-dev/pandas/issues/24950 For pandas 1.0, the current plan is to finally "just do it". The idea is that it should not take too long after 0.25.0, without additional major API changes (additions are fine of course) but with removing the current deprecated functionalities. Depending on how much feedback there is on 0.25.0 and on how smoothly it goes for removing deprecated stuff, we could (maybe optimistically) target September for that. Comments certainly welcome! Joris
What will be the deprecation procedures post 1.0? If a deprecation doesn't make it for 1.0, will that be an effective moratorium on deprecation for e.g. a year? I would actually like that stability, but that also means an extra effort to get all depecation done now could be worth an extra effort. -- Terji Petersen On Tue, Jul 16, 2019, at 10:56 PM, Joris Van den Bossche wrote:
Hi all,
We had some discussion about this on the in-person dev sprint end of June, and I thought it would be good to have some public record of this as well.
A pandas 0.25.0 release is close (the RC was released earlier this month), see https://github.com/pandas-dev/pandas/issues/24950
For pandas 1.0, the current plan is to finally "just do it". The idea is that it should not take too long after 0.25.0, without additional major API changes (additions are fine of course) but with removing the current deprecated functionalities. Depending on how much feedback there is on 0.25.0 and on how smoothly it goes for removing deprecated stuff, we could (maybe optimistically) target September for that.
Comments certainly welcome!
Joris _______________________________________________ Pandas-dev mailing list Pandas-dev@python.org https://mail.python.org/mailman/listinfo/pandas-dev
Op di 16 jul. 2019 om 19:14 schreef Tensortable.com < contribute@tensortable.com>:
What will be the deprecation procedures post 1.0? If a deprecation doesn't make it for 1.0, will that be an effective moratorium on deprecation for e.g. a year?
I would actually like that stability, but that also means an extra effort to get all depecation done now could be worth an extra effort.
We can still do deprecations in the 1.x releases, that is no problem. But how to handling removing deprecations and breaking changes in the versioning scheme is something we still need to discuss (eg "rolling deprecations" (each deprecation is kept for ca 3 releases, like we currently have been doing) or removing them in a version bump (like eg django does. Note we can do major version bumps more regularly than we did up to now ;)). But I would propose to have this discussion in a separate, dedicated thread.
-- Terji Petersen
On Tue, Jul 16, 2019, at 10:56 PM, Joris Van den Bossche wrote:
Hi all,
We had some discussion about this on the in-person dev sprint end of June, and I thought it would be good to have some public record of this as well.
A pandas 0.25.0 release is close (the RC was released earlier this month), see https://github.com/pandas-dev/pandas/issues/24950
For pandas 1.0, the current plan is to finally "just do it". The idea is that it should not take too long after 0.25.0, without additional major API changes (additions are fine of course) but with removing the current deprecated functionalities. Depending on how much feedback there is on 0.25.0 and on how smoothly it goes for removing deprecated stuff, we could (maybe optimistically) target September for that.
Comments certainly welcome!
Joris _______________________________________________ Pandas-dev mailing list Pandas-dev@python.org https://mail.python.org/mailman/listinfo/pandas-dev
_______________________________________________ Pandas-dev mailing list Pandas-dev@python.org https://mail.python.org/mailman/listinfo/pandas-dev
no we will still deprecate after 1.0 but we might need the deprecation to stay in longer ( maybe until a major version bump) though that simply means that we might bump major versions more often though we need to have some discussion about this
On Jul 16, 2019, at 7:14 PM, Tensortable.com <contribute@tensortable.com> wrote:
What will be the deprecation procedures post 1.0? If a deprecation doesn't make it for 1.0, will that be an effective moratorium on deprecation for e.g. a year?
I would actually like that stability, but that also means an extra effort to get all depecation done now could be worth an extra effort.
-- Terji Petersen
On Tue, Jul 16, 2019, at 10:56 PM, Joris Van den Bossche wrote: Hi all,
We had some discussion about this on the in-person dev sprint end of June, and I thought it would be good to have some public record of this as well.
A pandas 0.25.0 release is close (the RC was released earlier this month), see https://github.com/pandas-dev/pandas/issues/24950
For pandas 1.0, the current plan is to finally "just do it". The idea is that it should not take too long after 0.25.0, without additional major API changes (additions are fine of course) but with removing the current deprecated functionalities. Depending on how much feedback there is on 0.25.0 and on how smoothly it goes for removing deprecated stuff, we could (maybe optimistically) target September for that.
Comments certainly welcome!
Joris _______________________________________________ Pandas-dev mailing list Pandas-dev@python.org https://mail.python.org/mailman/listinfo/pandas-dev
_______________________________________________ Pandas-dev mailing list Pandas-dev@python.org https://mail.python.org/mailman/listinfo/pandas-dev
Hi all, In the meantime, September went by .. :) (as usual with 1.0 targets) See also https://github.com/pandas-dev/pandas/issues/17287 But on a more serious note: if we want to get a 1.0 out in the somewhat near future, I think we should do some planning for it / make decisions on what are blockers / organize some effort towards them (right now, I don't have the feeling there is much (coordinated) effort to get closer to 1.0, also from my side to be clear). - The initial idea was to remove all deprecations from pre 0.25 - Do we still want to do this? (I would say yes; according to our policy they otherwise need to stay until 2.0; we can of course update our versioning policy) - Is this a blocker? (probably not each and every one of them; but having done a majority of them might be? Or certain specific ones like .ix might be?) - Is there a way we can do some coordinated effort on this? Or try to get more contributions in this area? - In the meantime, also some specific features / improvements have been discussed that might want to get into 1.0. Are those blockers? - The missing values discussion. Given my personal involvement, I would like to see some basics of it in 1.0 (so the new StringArray can also already start using it). But it's also something that will take time to implement, so maybe that will get tight. - The block-wise ops performance improvement. Is this still targetted for 1.0? - Some API breaks we we still want to do in 1.0? There are several ExtensionArray related ones (eg the return value of .astype(..)) that might be nice. - See also the github milestone: https://github.com/pandas-dev/pandas/milestone/16 - ... ? - Is the website and docs redesign a blocker? To what extent do we want to delay for some of the blockers above? What are our current ideas for a timeline? The gihub milestone is saying December 1, but I don't think that is realistic. Joris On Wed, 17 Jul 2019 at 00:55, Joris Van den Bossche < jorisvandenbossche@gmail.com> wrote:
Hi all,
We had some discussion about this on the in-person dev sprint end of June, and I thought it would be good to have some public record of this as well.
A pandas 0.25.0 release is close (the RC was released earlier this month), see https://github.com/pandas-dev/pandas/issues/24950
For pandas 1.0, the current plan is to finally "just do it". The idea is that it should not take too long after 0.25.0, without additional major API changes (additions are fine of course) but with removing the current deprecated functionalities. Depending on how much feedback there is on 0.25.0 and on how smoothly it goes for removing deprecated stuff, we could (maybe optimistically) target September for that.
Comments certainly welcome!
Joris
I started going through the issues 1.0 milestone this morning. Hoping to finish all of them by the end of the day. On Tue, Nov 12, 2019 at 10:01 AM Joris Van den Bossche < jorisvandenbossche@gmail.com> wrote:
Hi all,
In the meantime, September went by .. :) (as usual with 1.0 targets) See also https://github.com/pandas-dev/pandas/issues/17287
But on a more serious note: if we want to get a 1.0 out in the somewhat near future, I think we should do some planning for it / make decisions on what are blockers / organize some effort towards them (right now, I don't have the feeling there is much (coordinated) effort to get closer to 1.0, also from my side to be clear).
- The initial idea was to remove all deprecations from pre 0.25 - Do we still want to do this? (I would say yes; according to our policy they otherwise need to stay until 2.0; we can of course update our versioning policy) - Is this a blocker? (probably not each and every one of them; but having done a majority of them might be? Or certain specific ones like .ix might be?) - Is there a way we can do some coordinated effort on this? Or try to get more contributions in this area?
I think not a blocker in general. But perhaps we could organize a mini-sprint (online) to knock a bunch out? We can do it as devs and invite community members to join in.
- In the meantime, also some specific features / improvements have been discussed that might want to get into 1.0. Are those blockers? - The missing values discussion. Given my personal involvement, I would like to see some basics of it in 1.0 (so the new StringArray can also already start using it). But it's also something that will take time to implement, so maybe that will get tight.
I'd consider delaying 1.0 a bit for this, but it's not absolutely necessary. We can also break small pieces off: StringArray can define and use it's own pd.NA, without larger changes.
- The block-wise ops performance improvement. Is this still targetted for 1.0?
Would be great to have this in. *Probably* not a blocker though. We can do
1.1 shortly after 1.0.
- Some API breaks we we still want to do in 1.0? There are several ExtensionArray related ones (eg the return value of .astype(..)) that might be nice. - See also the github milestone: https://github.com/pandas-dev/pandas/milestone/16 - ... ? - Is the website and docs redesign a blocker?
Happy to delay for a week or so, but not a blocker IMO. The nice thing there is we can continue to improve things after tagging the release. For major improvements to the docs, we can rebuild with a fake tag and reupload. To what extent do we want to delay for some of the blockers above?
What are our current ideas for a timeline? The gihub milestone is saying December 1, but I don't think that is realistic.
I think we'll have a better idea after the call tomorrow, but let's aim for a release candidate sometime in December. But people will likely be less active around the holidays, so a final release this year may be too ambitious.
Joris
On Wed, 17 Jul 2019 at 00:55, Joris Van den Bossche < jorisvandenbossche@gmail.com> wrote:
Hi all,
We had some discussion about this on the in-person dev sprint end of June, and I thought it would be good to have some public record of this as well.
A pandas 0.25.0 release is close (the RC was released earlier this month), see https://github.com/pandas-dev/pandas/issues/24950
For pandas 1.0, the current plan is to finally "just do it". The idea is that it should not take too long after 0.25.0, without additional major API changes (additions are fine of course) but with removing the current deprecated functionalities. Depending on how much feedback there is on 0.25.0 and on how smoothly it goes for removing deprecated stuff, we could (maybe optimistically) target September for that.
Comments certainly welcome!
Joris
_______________________________________________ Pandas-dev mailing list Pandas-dev@python.org https://mail.python.org/mailman/listinfo/pandas-dev
participants (4)
-
Jeff Reback -
Joris Van den Bossche -
Tensortable.com -
Tom Augspurger