Description
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.xwhere 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.