We can do that but I actually do not see what is so much better with that model. It just confused me. ;-) -Markus From: jaxrs-dev-bounces@xxxxxxxxxxx [mailto:jaxrs-dev-bounces@xxxxxxxxxxx] On Behalf Of Christian Kaltepoth
Sent: Mittwoch, 28. Februar 2018 15:00
To: jaxrs developer discussions
Subject: Re: [jaxrs-dev] Branches 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". 2018-02-26 21:52 GMT+01:00 Andy McCright <j.andrew.mccright@xxxxxxxxx>: My preference would be to have all forward development go into master - and the next release (whether 2.2 or 3.0 or whatever) should be based on that. I'm fine with a 2.1 service branch that is not the EE4J_8 branch, but eventually, that restriction should go away (I assume it goes away once we can certify that we have true Java EE 8 compatibility?) and then we would basically have two branches: master and the service branch (for bug fixes to JAX-RS 2.1 release). On Mon, Feb 26, 2018 at 11:57 AM, Markus KARG <markus@xxxxxxxxxxxxxxx> wrote: John, the difference between EE4J_8 and 2.1.1-SNAPSHOT is that *all* kinds of bug fixes go into 2.1.1-SNAPSHOT but according to the PMC's announcement only *criticial* fixes are allowed for EE4J_8. -Markus Hi Markus, thanks a lot for your reply. I really appreciate your detailed answer. I now understand the idea you had for these branches. If I understand you correctly, the buckets are more or less categories. So bug fixes should go to 2.1.1-SNAPSHOT but must not necessarily also be merged to 2.2-SNAPSHOT, or at least not immediately. And I now also understand why you didn't want to touch the master branch. I absolutely agree with you, that we need to find a way to collect patches contributed by the community as early as possible. However, I still think that a more simply model would work better. Let me comment on your concerns regarding the model I proposed: * We will conflict with PMC's decision as master would get changed.
AFAIK the PMC didn't decide that the master branch must not be changed. In the recent announcement the PMC just wrote that the master branch must be protected and that there must be a EE4J_8 branch for the planned EE8 compatible release. In item 7 they even wrote: "7. The Master branch will be used for changes that will go into the next platform release." So I think we are free to use the master branch for development...
Agreed, seems like the right place for it. * It is completely unclear what the next target of the HEAD of master is: A bug fix? Compatible changes? Incompatible changes? A mixture?
Well, I think it is common practice that the master branch will be the next minor (or major) version of a project. Patch releases are usually created from maintenance branches. So the master branch will eventually become the next release of JAX-RS under the Eclipse umbrella. There will never be an incompatible major release (like defined in SemVer). Instead, we will most likely release JAX-RS 2.2 or 3.0 next. And the "or" is important here. We won't work on two versions in parallel. Instead, we will continue to improve JAX-RS and release either 2.2 or 3.0 depending on how many features we get in. So I don't think that it makes sense to split work into a 2.2-SNAPSHOT and a 3.0-SNAPSHOT branch now. * We will have no place to merge features. 2.1.1 is intended to collect only bugs. Or do you want to mix them? Then you will have a problem in case you want to publish a fixes-only release one fine day; particularly large refactorings might then stand in your way of easily release a MR.
If my assumption that we are allowed to use the master branch is correct, then everything will simply go to master. And fixes can be cherry picked to the 2.1.1-SNAPSHOT or even the EE4J_8 branch if required. As you see, to have the most flexibility and not stop anyone from his current work, we do need the separation into the three proposed buckets. My proposal is a best practice implementing SemVer and it saved me from lots of trouble in the past 25 years rather often… Even if it induces complexity. :-)
I don't think that SemVer applies here. As noted above, we will never create incompatible releases. That's not allowed for such specifications. Therefore, the difference between 2.2 and 3.0 isn't that huge. So we actually have two branches, one for active development and one for bug fixes. And if we name the former one "master", we end up with the model I proposed. ;-) But hey, in the end this is up to social convention, so what do the others think?
I absolutely agree on this. All committers should discuss and decide on this. Just to sum up my proposal in a few words: - Keep the "EE4J_8" branch as requested by the PMC.
- Use the "master" branch for fixes, clarifications and new features.
- Cherry pick fixes to a "2.1.1-SNAPSHOT" maintenance branch and critical fixes to the "EE4J_8" branch (requires project lead / PMC approval)
The problem I see is if there are incompatible changes between master (or really any branch) and the EE8 branch, they will be difficult to cherry pick. I tend to favor the approach of merging bug fixes upstream. I also can't tell the difference between 2.1.1 and EE4J_8. They seem like they serve the same purpose. No new features, just bug fixes. Plus with having separate 2.2 and 3.0 branches, you're alluding to a release plan, which I don't think is necessarily the best option. In my opinion this is simple, straight forward and exactly how people expect it. Let me know about your thoughts... :-) -- _______________________________________________
jaxrs-dev mailing list
jaxrs-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jaxrs-dev
_______________________________________________
jaxrs-dev mailing list
jaxrs-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jaxrs-dev
_______________________________________________
jaxrs-dev mailing list
jaxrs-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jaxrs-dev
-- |
