Re: Branching for 1.1?

In principle this sounds like a good suggestion, but want to be sure on 
the practice before we decide in favor of it. If we are depending on 
editors cherry-picking frequently, what happens if someone forgets once 
and down the road we have to sort it out? Or if the branches deviate to 
the point that a cherry pick doesn't work without conflicts? That's 
especially likely if we expect to restructure the repository soonish. 
While cherry picking isn't super hard, for me it's a multi-step process 
that would feel like a slog to do with just about every single commit. 
Maybe that's the cost of being an editor, but maybe we can find an 
easier way.

I'll put the question on the agenda for the next editors' meeting but do 
keep up the list discussion, maybe it'll resolve. I just had these 
off-the-cuff "what if" questions.

Michael

On 12/04/2016 11:24 AM, Joanmarie Diggs wrote:
> 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
>