I'm not sure I can make the calls this week, but I'd like to weigh in.

I do not agree that deferral is the right move for these issues (or many of the others that I have submitted). They are breaking changes, and they should not be targeted at 1.0.1, but that doesn't mean we have to wait to work on them and think about them. Targeting an issue for version "2.0.0" does *not* have to mean deferral in the temporal sense -- that it gets worked on later, after other stuff happens. I strongly encourage this group to work on revisions in parallel. It's a very common practice in software engineering to have a "stable" release branch that gets small patches and fixes while work continues on the not-as-stable "development" branch that's targeting a new version. Often times, new features and fixes are worked on in the development branch, and then backported to the stable branch where it makes sense to do so. This is a large part of what semantic versioning enables, and I'm suggesting that UMA do the same.

Remember, we get to pick the version numbers and when we use them. We're not simply counting or picking from a fixed set. We don't have to exhaust the numeric space for "1.x" before we decide to work on "2.0". It could be that UMA 1.0.1 is the last UMA 1.x release ever. Or there could be a 1.0.2, or a 1.1.0, or anything like that. But none of that need to delay the 2.0 branch from starting.

If this were a project that I was running, I would create a branch in the repository today and tag it "2.0.x", and address 153, 154, and a handful of others in there. If anything can then be backported safely into the 1.0 branch, then let's do that.

In short: we don't have to wait, so let's not.
-- Justin

On 8/12/2015 10:40 AM, Eve Maler wrote:

This topic is on the agenda for discussion tomorrow.

In the case of issue 153/154, at least, there seems to be a definite leaning in the direction of deferral. If we lean that way for similar fundamental breaking issues, I added a column to the issue spreadsheet to imagine what the patch release workload might look like. The cells in bright yellow are my new proposals/questions for us to consider. You’ll also notice that I have proposed discussing and closing several issues tomorrow, in the pinkish color (mauve?).

Judging by our past work cadence, we can likely meet our agreed timeline if we go in the deferral direction. If we don’t, we probably need to seriously rethink the timeline and release strategy.

If you’ve got thoughts on the yellow cells ahead of the call (particularly if you can’t make the call), feel free to weigh in on this thread. Thanks,

Eve

Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com
_______________________________________________
WG-UMA mailing list
WG-UMA@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma