[Pandas-dev] On bug-fix releases and maintenance branches

tom tom.augspurger88 at gmail.com
Fri Feb 12 08:44:40 EST 2016


> On Feb 9, 2016, at 6:59 PM, Joris Van den Bossche <jorisvandenbossche at gmail.com <mailto:jorisvandenbossche at gmail.com>> wrote:
> 
> Hi all,
> 
> I wanted to stir some discussion on pandas its policy on bug-fx releases and upgrading pains. First some context:
> 
> Context part 1: Currently we do not use maintenance branches for bugfix releases, and we actually also do not really do bugfix releases. We just develop further on master, and try to not merge breaking changes the first weeks/months, so we can do a minor kind of bug-fix release (but usually also with a lot of new features).
> But we don't, for example, backport fixes of regressions if they are fixed after master is pointing to the next major release.
> 
> Context part 2: pandas is not yet that stable, in the sense that there are still quite some breaking changes in each release. I am not arguing for not doing these breaking changes, as some of these changes are really needed to clean up the API  (although there are also arguments for that, but I think that is another discussion). This has the consequence that updating your pandas version is not always that pleasant.

The third bit of context here is an eventual pandas 1.0. I could see us applying bug fixes to a pre-1.0 maintenance branch along side the 1.x branch initially. Perhaps it’s worth practicing that policy a bit before we get to 1.0.

> Sidenote: I have not that much experience with using pandas in a larger company or in larger codebases that need to be upgraded, rather with just my own code for my PhD. So it is difficult for me to judge on how much this is a problem or if bug-fx releases would help.
> 
> Questions:
> 	• What are other people's experiences with upgrading pandas? And would more bug-fix releases actually ease the upgrading?
> 	• Do we want to do more bug-fix releases?
> 	• Having a maintenance branch and backporting fixes is extra work. Would we be able to handle this? Would it be worth the effort? 
> (It has been mentioned before, but I think the main point raised was lack of manpower to maintain separate branches)
> 
> To put it another way. In our whatsnew notice there is "We recommend that all users upgrade to this version", but I am actually not sure we should recommend that. I personally do not always recommend that no matter what without careful consideration.

This <http://columbia-applied-data-science.github.io/pages/lowclass-python-style-guide.html> style guide was going around today, and it mentioned

> The basic Pandas API is still changing. When possible, production code should use numpy or standard Python.

The copyright on that page is 2012 so it could be a bit dated (it’s also copyrighted to Chang She among others). I do think pandas is at the point in its development cycle where we should be more conservative. And I think we have been a bit, but perhaps we can advertise that more.

> Regards,
> Joris
> _______________________________________________
> Pandas-dev mailing list
> Pandas-dev at python.org <mailto:Pandas-dev at python.org>
> https://mail.python.org/mailman/listinfo/pandas-dev

- Tom

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pandas-dev/attachments/20160212/d90d0323/attachment.html>


More information about the Pandas-dev mailing list