Versions post 3.1.0 release ?

[Rod Widdowson]

> I agree with the reasoning for the branch, but my take is that we would
have to
> push fixes to both because otherwise the merge back to get fixes applied
to the
> branch if we need to release it would be too hard. 

... That of course being where git cherry pick comes into its own.  In my
experience, as opposed to CVS and SVN where merging mostly doesn't work in
git cherry picking mostly does; this of course has the bad side effect that
it lulls you into a false sense of security in that something which is a
perfect textual merge may not be functional.

But that’s a side issue.  

> I guess what it comes down to is that late branching to me 

[...]  No argument on this.  We need a branch now before we start adding
function.

My questions are whether we afford the cost of checking *every fix* in to
both branches and of course testing?  Do we need to have Jenkins jobs for
both streams?  As Developers are we expected to bug fix again 3.1.1 and roll
patches forward to 3.1 or vice versa?  Which sort of changes would we be
merging? I made three checkins today just to clear up checkstyle I would not
expect to merge them; should I?.  

It looks like 3.2 is weeks away, are we really saying that if we have to do
a 3.1.1 release we'll be saying "here is a security release, it also
contains a whole bunch of bug fixes that you may or may not want"?  If not
what will we be saying?  That should provide guidance as what sort of bug
fixes we would put in.

I'm not saying that this doing any of this is a necessarily bad idea, I'm
saying that we (I really) need to understand upfront what the expected
behaviors will be.

> Whereas early vs. late branching is just timing/effort. The POM strategy
and
> versions are all defined as they are now.

Absolutely.  And for one I'd appreciate a nudge if people ever spot that I
have broken the "function change"/"pom bump" linkage.

/Rod