Release planning/milestones

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.



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 ?


Sandro Tosi (aka morph, morpheus, matrixhasu)

My website:

Me at Debian: