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