Ah, no I mean the exact opposite!
My proposal is to cut 2.0 off of what ever the current stable release is
(ex, 1.4.3) and then merge that into master. The next minor release would
then be 2.1 and there would be no new 1.Y releases.
Tom
On Sun Feb 08 2015 at 2:04:24 PM Sandro Tosi <mo...@debian.org> wrote:
> Hi all!
>
> On Sun, Feb 8, 2015 at 12:13 AM, Thomas Caswell <tcasw...@gmail.com>
> wrote:
> > Hey all,
> >
> > To start with, the 2.0 release is pending a choice of new default color
> map.
> > I think that when we pick that we should cut 2.0 off of the last release
> and
> > then the next minor release turns into 2.1. If we want to do other
> breaking
> > changes we will just do a 3.0 when that happens. It makes sense to me to
> > bundle default color changes as one set of breaking changes and code API
> > changes as another.
> >
> > Eric made the case in an issue that we should not continue the 1.4.x
> series
> > and start working 1.5.0, which fits well with aiming for a 6month
> scheduled
> > release cycle (minor release in July, bug-fix release in February).
>
> Do I understand correctly you plan to maintain 2 separate development
> lines (like Python with 2.x and 3.x) as 1.5.x and 2.x ?
>
> Cheers,
> --
> Sandro Tosi (aka morph, morpheus, matrixhasu)
> My website: http://matrixhasu.altervista.org/
> Me at Debian: http://wiki.debian.org/SandroTosi
>
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
