[Pandas-dev] Merging after the RC

Joris Van den Bossche jorisvandenbossche at gmail.com
Mon Jan 13 04:54:38 EST 2020


On Thu, 9 Jan 2020 at 20:04, Tom Augspurger <tom.augspurger88 at gmail.com>
wrote:

> On the call yesterday, we discussed branching strategies after we tag the
> RC.
> We're trying to keep the workflow roughly what it was before (with some
> terms
> changed). Briefly
>
> 1. Don't merge API-breaking changes to master. Those will need to wait
> until
>    the next *major* release (2.0.0) and we aren't ready to branch that yet.
> 2. We'll treat master as the next *minor* release. So performance
> improvements,
>    refactors, bug fixes, new features, will all be merged to master, as
> long as
>    they aren't API breaking changes.
> 3. Bugfixes fixing regressions that should be backported should be
> assigned the
>    milestone for the next bugfix release (e.g. 1.0.0, 1.0.1, 1.1.1).
>
> Use your best judgement when deciding whether something is a bugfix or
> breaking API.
>
> And it may have been mentioned briefly, but what are people's thoughts on
> what
> should be merged during the RC? IMO, it should be just PRs fixing
> regressions
> from 0.25.x. Everything else can just go in the next minor release, and
> needn't
> be backported.
>

I agree we should keep it mainly limited to fixing regressions. In addition
to that, I think we can also do:

- Non-regression fixes to *new* functionality (bugs in new things, or
feedback on new API)
- Remember that CI fixes often need to be backported as well, as we want to
keep CI green on the 1.0.x branch as well for now.



>
> I'm hoping to tag the RC later today.
>
> Tom
> _______________________________________________
> Pandas-dev mailing list
> Pandas-dev at python.org
> https://mail.python.org/mailman/listinfo/pandas-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pandas-dev/attachments/20200113/eac4b230/attachment.html>


More information about the Pandas-dev mailing list