| Re: [jaxrs-dev] Branches |
Anyways, what we actually do need rather soon is more input, so we can decide better. Looking at how few comments we have so far, and how many committers officially we are, I wonder what the others think? -Markus From: jaxrs-dev-bounces@xxxxxxxxxxx [mailto:jaxrs-dev-bounces@xxxxxxxxxxx] On Behalf Of Christian Kaltepoth Hi Markus, 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. Just my 2 cents. ;-) Christian 2018-03-01 18:57 GMT+01:00 Markus KARG <markus@xxxxxxxxxxxxxxx>: 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… -Markus From: jaxrs-dev-bounces@xxxxxxxxxxx [mailto:jaxrs-dev-bounces@xxxxxxxxxxx] On Behalf Of Christian Kaltepoth
Hey all, 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. Christian 2018-02-28 22:13 GMT+01:00 Markus KARG <markus@xxxxxxxxxxxxxxx>: Andy, I dislike the idea of "fork" instead of "branch". -Markus From: jaxrs-dev-bounces@xxxxxxxxxxx [mailto:jaxrs-dev-bounces@xxxxxxxxxxx] On Behalf Of Andy McCright
Christian, 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). Thanks, Andy On Wed, Feb 28, 2018 at 12:57 PM, Markus KARG <markus@xxxxxxxxxxxxxxx> wrote: 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
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:
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 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). Thanks, Andy 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 From: jaxrs-dev-bounces@xxxxxxxxxxx [mailto:jaxrs-dev-bounces@xxxxxxxxxxx] On Behalf Of John D. Ament On Sun, Feb 25, 2018 at 9:39 AM Christian Kaltepoth <christian@xxxxxxxxxxxx> wrote:
Agreed, seems like the right place for it.
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.
--
--
-- |