Branching for 1.1?

Hey all.

I was looking at the action item related to removing the text role from
the spec and preserving it for (re)inclusion in 2.0. To me, the real
RightThingToDo(tm) is to branch for 1.1 and leave master as our unstable
(towards 2.0) branch.

The advantages of this approach are:

* Tradition (you normally branch as you approach feature freeze so that
  work can continue uninterrupted in the unstable/master branch)
* No one has to wonder where the text role went: It's still in master.
  We can further clarify the stable + unstable situation by adding a
  new link to the top of each spec pointing to the 1.1 branch.
* No one has to locate and (re)merge the text role (and its mappings,
  and any authoring guidance) back into master when we begin working
  on 2.0 -- after having resolved any merge conflicts.

The only disadvantage I can think of is that editors will need to get
into the habit of committing changes to two branches when those changes
belong in 1.1 and 2.0. Speaking just for myself, I don't see this as a
disadvantage: Cherry-picking is quick and easy -- quicker and easier
than resolving merge conflicts down the road. ;) And it's a habit I'm
already in for development work.

What say y'all?
--joanie

Received on Tuesday, 12 April 2016 15:24:55 UTC