| All,
I removed 3-SNAPSHOT. Will try to merge all pending requests (some need more votes) into 2.2-SNAPSHOT and then merge that branch into master.
— Santiago
+1 In case I come across a PR which looks like a candidate for a major release, we can continue the dicussion regarding milestones. I think this is the right Github feature for such cases. -Markus Markus, If we don’t have any candidates for this bucket branch yet, and given that we don’t have a good solution for the problem either, why don’t we just remove the branch for now and revisit this later? — Santiago
Maybe it would be a good idea if we create a milestone "3" as a replacement for my original "3-SNAPSHOT" "bucket" branch and mark all "keep-for-later" PRs by moving them into that milestone? I think that would satisfy both, Christian's proposal of having less branches, and my proposal of having a "bucket" where I can keep the solutions for future picking. :-) if you merge such PRs into a "bucket branch" (which isn't synced with the main development branch by definition) the consequences would be even worse: You will have a bucket branch with changes from _many_ pull requests which diverged from the main development branch for quite some time. This would be even more difficult to merge later on. The (only?) advantage of keeping PRs open for such changes would be that you get rather small changes which are more likely to don't result in conflicts and you can even switch target branches for the PRs directly in GitHub if you decide to merge it somewhere else (like directly to "master"). However, how to handle changes which shouldn't go into the main development branch immediately is a matter for taste. Another alternative would be to use feature branches for such changes. So we could for example create a branch "deprecate-at-context" and merge a corresponding PR into this branch. This way we get the advantage of rather small changes per branche and we don't keep PRs open too long. I do not see how merging gets any better when keeping PRs open for months or possibly years. My experience is that things that are complex to merge now will get impossible to merge in future. Hence, keeping PRs open for long time is explicitly not what I want, as it definitively will render the developed solution worthless. The contributors will not remember what they did, how they did it, and why they did it that way, when you try to merge their contribution after several months…
To: jaxrs developer discussions
Subject: Re: [jaxrs-dev] Branches
I agree with Andy's words about the advantages of the proposal: Fewer branches, development happens in "master" like everybody expects it and using bucket branches instead will lead to merge hell when the branches diverge after some time. I'm not completely sure how to handle the "3-SNAPSHOT" branch. If we work on master for some time and only a few commits go to "3-SNAPSHOT", merging will get more and more difficult. If there are changes which we don't want to merge today, what about just keeping the PRs open and tagging them with "future". Wound't this be a good alternative. I don't expect too many changes that would be affected by this. I dislike the idea of "fork" instead of "branch".
To: jaxrs developer discussions
Subject: Re: [jaxrs-dev] Branches
I like your proposal, with one exception - instead of: · 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. I'd prefer we get rid of the 3.0-SNAPSHOT branch entirely. My preference would be that if there is some new piece of forward development that we don't want in master, that it should belong in a separate fork rather than a branch in the this repo. Otherwise, I think we'd need to continually push changes from master into 3.0-SNAPSHOT to keep them in sync (except for the "too experimental" changes). If others prefer to keep the 3.0-SNAPSHOT though, I can be persuaded. Markus, the main advantage is fewer branches - and thus, fewer deliveries to multiple streams (and less merge conflicts! ;-) ). I think it is also more familiar to many developers (in both OpenLiberty and CXF, we use master for our forward development and then have separate streams for service/maintenance releases). We can do that but I actually do not see what is so much better with that model. It just confused me. ;-)
To: jaxrs developer discussions
Subject: Re: [jaxrs-dev] Branches
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". 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). 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. 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
_______________________________________________
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
|
