From: Thomas C. <tca...@gm...> - 2015-02-08 19:11:11
|
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...@de...> wrote: > Hi all! > > On Sun, Feb 8, 2015 at 12:13 AM, Thomas Caswell <tca...@gm...> > 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 > |