Hey all,
thanks a lot for your feedback.
@Markus: Ok, I agree that there are changes (especially deprecations) which somehow belong into the "breaking" category as defined by semantic versioning. And having a separate branch for this seems reasonable.
But it also looks like John and Andy agree with me that active development should go into the master branch. And it doesn't look like this conflicts with the requirements of PMC.
So what do you think about:
- We merge "2.2-SNAPSHOT" into master and remove the "2.2-SNAPSHOT" branch
- Active development goes into master (fixes + new features)
- Critical bug fixes can be cherry picked from master to "EE4_8" (assuming the spec lead agrees for the corresponding fix)
- Critical + non-critical fixes can be cherry picked from master to "2.1.1-SNAPSHOT". This way we have a branch ready if we want to do a MR version or publish an updated version of the API jar to Maven central.
- Changes which we don't want to see in the active development branch should go to "3.0-SNAPSHOT". We can decide about what we do with them later on.
Does this makes sense? This way we move from the "bucket branch model" (where each change goes into exactly one bucket) to a model where most development happens on master which represents the "next version".
Christian