Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-spec-project-leads] Merging of EE4J_8 branches?


On Tue, 10 Mar 2020 at 20:07, Bill Shannon <bill.shannon@xxxxxxxxxx> wrote:
Tom Jenkinson wrote on 3/10/20 3:16 AM:

2. Similar to https://wiki.eclipse.org/JakartaEE_New_Infra_Release_Job Specific, version change commits themselves do not even appear on the EE4J_8 branch
I would expect them to appear on master.

I can certainly start doing that. I think we should address that at the Wiki article though, unless Jakarta Transactions is the only project not doing that and I misinterpreted https://wiki.eclipse.org/JakartaEE_New_Infra_Release_Job somehow.

That process creates a branch, which you then have to merge and discard after you're sure the release is correct.  The version change commits then appear on master.

I see, I did not understand that was the expectation.

Looking at https://github.com/eclipse-ee4j/jta-api/pull/new/RELEASE-2.0.0-RC1 I was struck that it would not leave master on a SNAPSHOT version for the project. Looking more I think I must have edited the original script to no longer do the SNAPSHOT if the NEXT_VERSION was the same as the original SNAPSHOT version. I have removed that step now I understand the purpose of this RELEASE- prefixed branch.

But then, having raised https://github.com/eclipse-ee4j/jta-api/pull/91 (which has the commit used in the 2.0.0.RC1 tag https://github.com/eclipse-ee4j/jta-api/commit/178cd37b687c9bba22448c407a1bfb1457fc6e6b meaning I could delete the branch RELEASE-2.0.0-RC1, plus a commit to move master back to the 2.0.0-SNAPSHOT straight after) you will see that the jta-bot fails the legal agreements check so the PR can't be merged anyway. Do others have the same problem with PRs containing commits from their projects "bot" account?

In terms of the RELEASE-1.3* branches and the EE4J_8 branches, I am now wondering what the best thing for Jakarta Transactions is as I don't know a way to get those commits back into master without perhaps some history rewriting. Perhaps what I could do is protect the RELEASE-1.3.3 branch, given that was the EE4J_8 release, and delete some others branches, although that could in theory lose the commits for 1.3.1 and 1.3.2 at some point. Further complicating this, looking at https://github.com/eclipse-ee4j/jta-api/commits/RELEASE-1.3.2 and https://github.com/eclipse-ee4j/jta-api/commits/1.3.2 (and similarly for 1.3.1) they don't seem to have the same SHA-1 for commits used to move to the released version anyway (although RELEASE-1.3.3 and 1.3.3 do seem to share the SHA-1). If we really want to preserve the 1.3.2 and 1.3.1 tagged commits, I could reset their corresponding branches to the tagged version and try yo protect them too. If that is what we want to do then I think it should be OK to lose the commits currently on those branches that updated the branches to the respective version, and also lose the subsequent commits that move that branch to the next snapshot version.

In summary:
1. Work out how to get a PR merged with a commit from the bot user so https://github.com/eclipse-ee4j/jta-api/commits/RELEASE-2.0.0-RC1 can be deleted
4. If we don't need to try to protect the commits for 1.3.1 and 1.3.2 then delete https://github.com/eclipse-ee4j/jta-api/commits/RELEASE-1.3.1, https://github.com/eclipse-ee4j/jta-api/commits/RELEASE-1.3.2. If we do want to try to protect them then reset each of those to their respective tag commits, which would lose their SHA-1 commit sets the files to a release version and loses their commits which moves them to the next snapshot. We would then try to force push those branches and protect them.

Back to the top