Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jaxrs-dev] Branches
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...


* 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)
In my opinion this is simple, straight forward and exactly how people expect it.

Let me know about your thoughts... :-)

Christian


--
Christian Kaltepoth

Back to the top