matplotlib-devel

[matplotlib-devel] Release schedule

[Thomas C. <tca...@gm...>]

Following up on the last email,  I would like to aim for a 1.5 release at
the end of July, with the sprint at scipy being focused on finishing it
off.  The 2.0 color/style release will happen (hopefully soon) after that.

Does this schedule seem ok to everyone?

I have started to triage the issues/PRs tagged as 'next point release', if
anyone has issues/PRs they consider blockers please tag them as release
critical or leave a note.

Tom

Re: [matplotlib-devel] Release schedule

[OceanWolf <jui...@ya...>]

The only concerns on doing 1.5 -> 2.0 come from the huge amount of extra work in uncherrypicking recherrypicking.  Given the amount of testing that both master and color-overhaul have gone through by us devs and other interested people, I feel it perhaps better to keep the release schedule as it was.

>From the perspective of working on MEP22/27 it would feel nice to do a 1.5 and then depreciate (or fully-remove) in 2.0, but personally I opt for safety over nicety (plus it gives us more time to get MEP22/27 completed and have time for more people to test it, find bugs, though I doubt we will have any O:)).


Best,
OceanWolf

Re: [matplotlib-devel] Release schedule

[Thomas C. <tca...@gm...>]

I am not sure what you mean by cherry-picking/uncherry picking.  I just
looked at what is on `color_overhaul` which is not in master and it is:
changes that should be discarded (changes to cxx / changes to _tri.* that
rely on cxx), one change related to mathtext layout (and conflicts due to
mathext_*68 being added on both branches) which we do not want to cherry
pick, and documentation about pkg-config and a minor doc which will be easy
to cherry-pick (I am going to do in now).

There is documentation about the coming color change in master, but that is
probably ok to include in a point release (as it is just plans).

In either case the 2.0 release will contain _only_ style related API breaks
and will be based on what ever the last point release was.

Tom

On Tue, Jun 16, 2015 at 9:15 AM OceanWolf <jui...@ya...>
wrote:

> The only concerns on doing 1.5 -> 2.0 come from the huge amount of extra
> work in uncherrypicking recherrypicking.  Given the amount of testing that
> both master and color-overhaul have gone through by us devs and other
> interested people, I feel it perhaps better to keep the release schedule as
> it was.
>
> From the perspective of working on MEP22/27 it would feel nice to do a 1.5
> and then depreciate (or fully-remove) in 2.0, but personally I opt for
> safety over nicety (plus it gives us more time to get MEP22/27 completed
> and have time for more people to test it, find bugs, though I doubt we will
> have any O:)).
>
>
> Best,
> OceanWolf
>

Re: [matplotlib-devel] Release schedule

[OceanWolf <jui...@ya...>]

I think I mean that before we cherrypicked from master to colouroverhaul, as we only wanted a few things from master to go out in the next release, but now if I understand correctly we want most of master to go out in the next release, so we have to uncherrypick out the stuff we don't want, and I fear that such a branch won't have had the rigorous testing that the current color-overhaul branch has had.  Metaphorically speaking we have a mixture of different fluids that have settled into clear stratified layers, now we plan to give that mixture a good shake and hope we don't break everything.

Meh, perhaps I just act too overcautious.

________________________________
From: Thomas Caswell <tca...@gm...>
To: OceanWolf <jui...@ya...>; "mat...@li..." <mat...@li...> 
Sent: Wednesday, 17 June 2015, 6:04
Subject: Re: [matplotlib-devel] Release schedule



I am not sure what you mean by cherry-picking/uncherry picking.  I just looked at what is on `color_overhaul` which is not in master and it is: changes that should be discarded (changes to cxx / changes to _tri.* that rely on cxx), one change related to mathtext layout (and conflicts due to mathext_*68 being added on both branches) which we do not want to cherry pick, and documentation about pkg-config and a minor doc which will be easy to cherry-pick (I am going to do in now).

There is documentation about the coming color change in master, but that is probably ok to include in a point release (as it is just plans).


In either case the 2.0 release will contain _only_ style related API breaks and will be based on what ever the last point release was.

Tom




On Tue, Jun 16, 2015 at 9:15 AM OceanWolf <jui...@ya...> wrote:

The only concerns on doing 1.5 -> 2.0 come from the huge amount of extra work in uncherrypicking recherrypicking.  Given the amount of testing that both master and color-overhaul have gone through by us devs and other interested people, I feel it perhaps better to keep the release schedule as it was.
>
>From the perspective of working on MEP22/27 it would feel nice to do a 1.5 and then depreciate (or fully-remove) in 2.0, but personally I opt for safety over nicety (plus it gives us more time to get MEP22/27 completed and have time for more people to test it, find bugs, though I doubt we will have any O:)).
>
>
>Best,
>OceanWolf
>