[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jakartaee-spec-project-leads] Merging of EE4J_8 branches?
|
Tom Jenkinson wrote on 3/11/20 4:57 AM:
Tom Jenkinson wrote on 3/10/20 3:16 AM:
I would expect them to appear on master.
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.
I updated
https://wiki.eclipse.org/JakartaEE_New_Infra_Release_Job.
If it's still not clear, let me know, or better yet, update it
yourself.
I assume everyone is just copy and pasting the script in the
"Project pom.xml in a Subdirectory" section. (Otherwise it seems
that you have to copy and paste each fragment of the script above,
which seems very error prone.) It would be nice if this section
were synchronized with the sections above.
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.
I don't use this script myself, but I believe this is a common
problem.
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.
You might need a git expert to help with that; definitely not me!
:-)
Lacking that, just do the simplest thing that ends up with the right
state, and don't worry about missing or lost commits in the middle.
It's not worth rewriting history to make it look nice.
I think you can just ignore the validation check. If that doesn't
work, maybe ask Wayne for help with this, or file a web issue.
Why do you need to protect this?
Yes.
Like I said, I don't think it's worth rewriting history. Just make
it correct now, and do the right thing going forward.