Closed jamezp closed 4 months ago
So if master becomes the new 4.0 for EE11, isn't it confusing to have a 3.2 branch? I know that it is experimental, but seems a bit odd for its number to be lower. Maybe I'm missing something.
So if master becomes the new 4.0 for EE11, isn't it confusing to have a 3.2 branch? I know that it is experimental, but seems a bit odd for its number to be lower. Maybe I'm missing something.
TBH I completely agree. I'm just not sure what to do. The master branch is out of date. The release-4.0 branch can't really become master unless we revert some things like removing the the @Context
and @Suspended
annotations along with their respective documentation. The release-4.0 branch also has the TCK module commented out so it doesn't compile it and really it can't because of the removed annotations.
Both master, release-3.2 and release-4.0 include #1066 so we need some kind of version bump in master. If we remove the XML Binding dependency, then it needs to be a major bump.
In the end this seemed like the best middle ground. There really should be another commit on top of this, which I can add, that updates the signature test file too because it is missing the singantures from #1066 and the signature change from #863.
IMO none of the branches are in a releasable state. I will go ahead and add the commit to update the signature files to this PR too. I think that is critical too. Whether we go with this PR or not is fine, but IMO we do need some branch in a releasable state.
I've added the additional commit to update the signature test plugin and file.
Please note this is just my opinion on what would get the branch where we need it. I wanted to propose it so we could have a path forward. Given, AIUI, this would take at least two weeks to get merged, that leaves with about two more weeks to get anything else done for Jakarta EE 11. We're due to have something by 29.Mar.2024, unless the schedule gets pushed.
Given, AIUI, this would take at least two weeks to get merged, that leaves with about two more weeks to get anything else done for Jakarta EE 11. We're due to have something by 29.Mar.2024, unless the schedule gets pushed.
I've added "fast track" to the title. Since the changes in this PR have all been reviewed and approved in other PRs it seems logical to allow this to be fast tracked.
So if master becomes the new 4.0 for EE11, isn't it confusing to have a 3.2 branch?
I can rename the "release-3.2" branch to "release-4.1" to remove confusion. If for some reason the EE11 schedule gets pushed out and the group feels comfortable with the content in the release-4.1 branch, I'm assuming we could apply it to 4.0.
For ease of review I've done the copyright date updates in a separate commit. If preferred, I could do the updates within the correct commit the file was changed in.
Merging
This PR is comprised of several commits that are in the release-3.2 and release-4.0 branches that should likely be in master. It also takes the liberty of change the master branches version from 3.1.0 to 4.0.0-SNAPSHOT. This was primarily done to prepare for a slimmed down 4.0.0 for Jakarta EE 11 as described in https://www.eclipse.org/lists/rest-dev/msg00231.html
Associated PR's that comprised this PR:
1211
1217
1220
Just for a reference too, this PR includes the following commits from release-4.0:
1182
1172
1145