Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jaxrs-dev] Branches
All,

 I agree with Andy and Christian. The whole idea of a 3-SNAPSHOT branch is a bit of a red herring. We can decide what to do with those contributions if/when they come —we certainly shouldn’t be thinking about breaking backward compatibility yet :)

 To recap:

 (1) Merge 2.2-SNAPSHOT into master and remove it

 (2) Development into master

 (3) Critical fixes to EE4J_8 (requires TCK run for each fix)

 (4) Fixes into 2.1.1-SNAPSHOT in case we do an MR-like release

 (5) Remove 3.0-SNAPSHOT 

 The only question I have is related to protected branches. We currently don’t seem to have admin permissions to tweak protection. Anyone knows more about how this works? I believe master is protected at the moment.

— Santiago

On Mar 1, 2018, at 1:37 AM, Christian Kaltepoth <christian@xxxxxxxxxxxx> wrote:

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@eclipse.org] On Behalf Of Andy McCright
Sent: Mittwoch, 28. Februar 2018 21:04


To: jaxrs developer discussions
Subject: Re: [jaxrs-dev] Branches

 

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@eclipse.org] 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".

 

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@eclipse.org] On Behalf Of John D. Ament
Sent: Sonntag, 25. Februar 2018 18:27
To: jaxrs developer discussions
Subject: Re: [jaxrs-dev] Branches

 

 

On Sun, Feb 25, 2018 at 9:39 AM Christian Kaltepoth <christian@xxxxxxxxxxxx> wrote:

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... :-)

 

Christian

 

 

--

_______________________________________________
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




--
Christian Kaltepoth

_______________________________________________
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

Back to the top