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 <tcasw...@gmail.com> To: OceanWolf <juichenieder-n...@yahoo.co.uk>; "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-n...@yahoo.co.uk> 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 > ------------------------------------------------------------------------------ _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
