Start a second branch to work on a version 6 of this library?

[jmini]

Context:

While there are a lot plans for the future (#817, #924, #925 and other issues with the Next label), it seems that we need also to think short term here.

The most wanted feature is to have a version of this library that is compatible with Spring Framework 6.0 (Spring Boot 3) which requires a Jersey client version update and the package change javax.ws.rs.* -> jakarta.ws.rs.* which is presented in PR #841

---

Branching model:

It seems reasonable to me to start a second main branch jakarta or 6.x.x or master/6.x.x next to the master branch (our current default branch dedicated to 5.1.0) to put the changes requested by the Spring community to have a version using jakarta.

As commented by @marcelstoer here #841 (comment) we could have the 2 versions in parallel for a while.

For the branching model, I personally prefer a pattern with forward merge instead of doing cherry-picks.

We have 2 main branches:

• one to work on 5.x.x (the current version, java 8 &javax.ws.rs.* -- could stay the default branch for now)
• one to work on 6.x.x where we would do have the breaking changes (jakarta.ws.rs.* namespace change in particular)

We always merge in the 5.x.x -> 6.x.x direction, not in the other way around.
We are sure that all the changes in 5.x.x are properly merged into 6.x.x.

💡 I wrote a more detailed description about this branching model that we are using in all our projects in my company.

---

Scope:

If we want to have something quick, I think it makes sense to keep the 6.x.x as close as possible to 5.1.x for now.

So for me this would mean:

• PR Migrate from javax to jakarta #841
• PR Add java9+ and Jakarta EE Support #895 (maybe)
• Java 11 as baseline (also not really mandatory)

And do a 6.0.0-rc.1 or a 6.0.0-beta.1 (not sure what is the preferred versioning scheme) really soon, so that we can get feedback from the community that uses Spring.

Other bigger refactoring tasks would be moved to a later version:

• Elimination of the Jersey client Replace the underlying HTTP client #924
• Move to java 17
• Having too much overloaded methods for the same endpoint to handle all the optional parameters
• Work on the consistency of the Api class.
• Removal of the support of the GitLab API v3
• ...

This would make version 6 a breaking version for technical reason.
And make an other next major version (which would be version 7), where we could include more functional breaking changes, more cleanups, ... (and so on). We would have more time to figure out what needs to be done with this next major version.

---

Risk:

The risk of not doing a version compatible with the Spring Boot 3 is to fragment the project (some people will start their one version of this library).

To me this is more important than not being able to do all the breaking changes in one version.

I would also not keep this dual versioning for a too long period of time, because it is time-consuming and requires additional efforts, but in this way I think this is a good way to move forward quickly.

---

Feedback

This is open for feedback now, maybe we can give us until end of March 2023 to have a decision.

[hemju]

👍 for a fast upgrade to Spring 3. Whatever way is the fastest way for you maintainers.

As Jürgen Höller mentioned in his keynote, Spring (Boot) switches to a much faster release cycle. Which in my opinion will also affect the Java ecosystem since Spring is such a huge player.

[jabby]

Hi @jmini,

I agree with your proposal. I assigned this to myself. I will create all necessary branches (at least the one for version 6.x).

[jmini]

Let me know when the branch is created so that I can start doing the necessary changes.

[hemju]

Are there any updates on this issue? I can't find a version 6.x branch yet. Is this PR #943 actually something that will get merged?

[jmini]

The branch 6.x to work on 6.x.x was created.

I have started to do the changes.

[jmini]

Since name of the branches are now defined, I have updated the Git flow diagram (editable with diagrams.net):

Read more about the approach

[jmini]

When we implement the separation in multiple modules (see #1067) we can have a jersey 2 implementation next to a jersey 3 implementation.

At this point we will merge 6.x back into main and and work only on the 6.x.x version.

[weinbergalfredo]

Hi. I'm trying to set the merge_commit_template using ProjectApi. I've noticed that it was introduced in 6.X
I'm using the 6.0.0-rc.4 maven dependency downloaded from maven central and I don't see those changes in the source code.

Is 6.0.0-rc.4 uploaded to maven central repo?
Thank you very much in advance

Best regards

[marcelstoer]

There are a number of changes that landed on main after RC4 was released: gitlab4j-api-6.0.0-rc.4...main Support for [issue|merge|squash]_branch_template is one of them.

[jmini]

We currently have 2 branches:

• main where we continue to work on the 5.x.x version.
• 6.x where we have a version that is using the jakarta namespace (6.x.x version, currently only RCs published)

[jmini]

Release 5.8.0 is the last release on the 5.x.x stream.

I have merged the branch 6.x into main and I removed it.
I will do only 6.x.x releases.

[marcelstoer]

That's great news, thanks! Looking forward to the GA 6.0 release (been on RCs for quite a while now).

[jmini]

@marcelstoer testing 6.0.0-rc7 would be very important since I separated the project into 2 modules (see #1067)

Maybe one last goal for 6.0.0 would be #1202

[jmini]

For 6.0.0 I think that solving #1210 is also very important