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 <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 >
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 >