Firstly the default branch is 'master' but that is still producing javax artefacts instead of jakarta artefacts. Generally in a git repository the default branch is where you would expect ongoing upstream development to occur but this branch is behind the latest release.
The latest release (1.0.1 branch) in this case was a "re-release", namely the one for the GlassFish 5.1 release last January.
Next we have the EE4J_8 branch, this does seem to be producing jakarta artefacts but the version is currently 1.0.1-SNAPSHOT so effectively behind the current release.
The EE4J_8 branch was a "special" branch that all EE4J_8 projects got and was reserved for the transfer and the GlassFish 5.1 release.
Finally there is a 1.0.1 branch, this appears to have further commits added to move it after the 1.0.1 release but has no SNAPSHOT qualifier which is generally something you would expect if the branch is an active development branch to avoid accidentally populating with intermediate builds that are not qualified as being a SNAPSHOT build.
This branch has been generated by the release script. If you look carefully at the last few commits you see it's been committed to by the release bot. Many/most EE4J projects have such branch, as it was in the original release script on which most if not all other release jobs were based. I think it should have set the branch to SNAPSHOT though. Could potentially be a copy/paste error in the release script.
Additionally if the latter branch is intended to be an ongoing maintenance branch wouldn't a name like "1.0.x" or "1.0" be more appropriate?
The 1.0.1 branch is as mentioned an artefact from the release process. I'm not 100% sure what the original intention was for such branches, the one who created the original release script probably knows. Indeed, an ongoing maintenance branch should be named "1.0.x" or "1.0".
It is the idea though that these branches should be merged to master indeed. In the case of Soteria, work for 1.1 had already started before the re-release came in, if I'm not mistaken. I'll at least merge 1.0.1 into master.
Now we again have another special case with the javax -> jakarta namespace transition. We'll have to decide which branch to target for Jakarta EE 9.
Kind regards,
Arjan
So I think primarily I am trying to identify where to submit fixes for 1.0.x releases but also if there is any upstream synchronisation to consider.
Personally I am a fan of using `git merge` to synchronise between maintenance branches and active development branches but I know within the industry there is still a preference to manually porting commits between branches.
Regards,
Darran Lofthouse.
es-dev mailing list
es-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/es-dev
