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 <morph@…12…> wrote:
Hi all!
On Sun, Feb 8, 2015 at 12:13 AM, Thomas Caswell <tcaswell@…149…> 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