Release schedule

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

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

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 <juichenieder-nabb@…705…> 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

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 <tcaswell@...149...>
To: OceanWolf <juichenieder-nabb@...705...>; "matplotlib-devel@lists.sourceforge.net" <matplotlib-devel@lists.sourceforge.net>
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 <juichenieder-nabb@...705...> 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