| Re: [jaxrs-dev] Branches |
Christian, I understand your concerns and like to explain why I proposed the current complexity. It was clearly my fault not to expain more deeply when I proposed that branches, so let me do now: * For an unspecified time, we must not merge into master. This was a PMC decision. I assume once the TCK and Spec are migrated, the PMC will allow that, but for now, I need a place to merge. * There is nothing like a "main development" branch, as everybody is free to contribute what he likes, at any time. We are no company with a plan who works on what and when. The PMC's agenda might be to only create Java EE 8 compatibility, but others are working on additional stuff, and that stuff has to go somewhere, and that stuff is valueable. * People simply do work on bugs and features right now and I didn't want to stop them, because they would lose their interest and go away. It is essential for PR management that we have places to "offload" the PRs right now. As we have not even discussed which releases we will provide in future (independent of the PMC's agenda), we must have separate "buckets" to fill them in now. So I created "buckets" for bugs, compatible features, and incompatible features. It is allowed and intended that people work on everything at the same time. The naming follows SemVer and are pretty clear: A potentional successor of 2.1 would be named 2.1.1 in case it is holding only bug fixes, 2.2 when holding any compatible changes, 3 when holding any incompatible changes. Whether or not we will ever publish such changes is not decided. Again, I created it solely as "buckets" to separately collect work which contributors have finished right now. * Once we decided for actual releases (we not even started this discussion), we can safely either cherry-pick from these "buckets", or we can decide to simply publish a complete "bucket" as-is, and then rebase or merge into the "upgrade bucket" (2.1.1 -> 2.2 -> 3). Thanks to the clear separation of buckets, this is more or less a no-brainer, as the most conflicting changes are done in the topmost "bucket". If we would follow your proposal, we would have the following drawbacks: * We will conflict with PMC's decision as master would get changed. * It is completely unclear what the next target of the HEAD of master is: A bug fix? Compatible changes? Incompatible changes? A mixture? * 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. 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. :-) But hey, in the end this is up to social convention, so what do the others think? -Markus From: jaxrs-dev-bounces@xxxxxxxxxxx [mailto:jaxrs-dev-bounces@xxxxxxxxxxx] On Behalf Of Christian Kaltepoth Hi everyone, I know that this has been discussed before, but I've some concerns about how branches are currently set up in the jaxrs-api repository. Beside the required "EE4J_8" branch, there are 4 other branches:
I think this setup is confusing for a number of reasons:
I wonder if we shouldn't simplify the branch model. I was thinking about only 2 branches (beside the required "EE4J_8" of course):
As you see, this model is MUCH simpler. And I think it is not confusing for anyone, because it follows the standard pattern to have a master branch for active development and maintenance branches which can get bug fixes from the master branch. And the branch model will be compatible with the rules published by the PMC if "master" is a protected branch. What do you think? Christian |