-
Notifications
You must be signed in to change notification settings - Fork 41
Enforcing JDK 11 on release #148
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enforcing JDK 11 on release #148
Conversation
@olamy @michael-o Please review this PR. I will keep it in draft state until you vote with +1 and I pretend to squash it before merging. :-) |
my understanding of draft vs not draft is draft means not ready for review vs ready for review. |
My understanding of draft is "not ready for merge, but ready for review", so I did that to express that the code possibly will change due to the incoming change requests. |
interesting point of view and workflow. |
non-draft means "ready to merge". Nothing else. Can still be reviewed. The sole point about "draft" mode is that it prevents clicking "merge" too early. |
@olamy @rfscholte This PR introduces the enforcement you requested. I answered your questions, and you did not further respond. So I would like to propose that you post a +1 when you want me to merge this one, or clearly request changes otherwise. |
please follow the usual workflow and remove draft status saying it's ready for review. |
In other projects I am contributing to, I was explicitly asked to keep in draft mode unless no more commits are expected to be put ontop (i. e. the committers are coaching the PR author towards a state that looks like all would be +1, hence the PR changes heavily). So please clearly tell me how that "usual" way is like. Currently I am still adding commits ontop as while the reviews run, change request do appear. Hence, when do committers know when to finally vote if not by the day it turns from draft to non-draft? So shall this really happen outside of draft mode? Just need to get a confirmation on that, and I will do that. Again, this is not that I want to propose another process or want to discuss yours, I just need to know how you want it. :-) |
Fixed last change request, no more discussions unanswered, no -1 so far => switching from draft to non-draft now. Thanks to everybody for the feedback to the draft. Committers, please cast your VOTE now! :-) |
Enforcing the use of JDK 11 on release guarantees that the published Multi-Release JAR contains ALL code versions: JDK 8 (default fallback), JDK 9 (enhanced NIO) and JDK 10 (even further enhanced NIO). Without this enforcement, there would be a risk of not having some of these versions packed into the MRJAR due to the way the POM checks for the existence of supported JDK levels using JDK-enabled profiles.
b350202
to
17ad39e
Compare
Enforcing the use of JDK 11 on release guarantees that the published Multi-Release JAR contains ALL code versions: JDK 8 (default fallback), JDK 9 (enhanced NIO) and JDK 10 (even further enhanced NIO). Without this enforcement, there would be a risk of not having some of these versions packed into the MRJAR due to the way the POM checks for the existence of supported JDK levels using JDK-enabled profiles.
This PR was requested by @olamy in #120 (comment), and is effective only in the
plexus-release
profile as requested by @rfscholte in #148 (comment). While it technically would be enough to just enforce JDK 10, and while it would be more future-proof to even enforce JDK 16, it follows @olamy 's preference mentioned in #120 (comment), hence enforce JDK 11 instead.