On Mon, Apr 21, 2014 at 9:26 AM, Graham Leggett <minfrin@sharp.fm> wrote:
On 21 Apr 2014, at 3:16 PM, Jeff Trawick <trawick@gmail.com> wrote:

r1588878, and soon if practical, given we've just released v1.5.1.

What does that commit have to do with having just released 1.5.1?

The commit is an addition to the API, and as such as not eligible for backport to the v1.5.x branch as per our versioning rules. Having just released v1.5.x people may not be keen on v1.6 so soon after, or maybe they are. Either way no way to tell, seeing v1.6.x doesn't exist.

1.5.1 wasn't the first release in the 1.5.x series.


New features seem rather easy to follow using trunk/CHANGES and-or a diff of the include directories.  For finer detail, it is much easier for a person who cares to record revision numbers of desired feature backports in trunk/STATUS than for everyone to have to touch an additional branch for bug fixes, and then double check before we actually release it since we've had issues with that in the past.

The shortcut you're describing is technical debt. Instead of the person who wants the fix and/or feature committed doing the work of committing it to various branches that work falls to others who are probably not in a position to make the backport as carefully or test it as thoroughly. This introduces stability problems we just don't want.

Let's bring this down to earth.  Do you to promote a 1.6.x branch/release soon-ish (e.g., within a month or so) and discuss what new features various developers are interested in promoting for 1.6.x, or do you just want to have the branch pick up changes steadily until 1.6.x gradually acquires different constituencies that want/need a feature relase?

Born in Roswell... married an alien...