-
Notifications
You must be signed in to change notification settings - Fork 39
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
allow test with pekko 1.0.x snapshot #333
allow test with pekko 1.0.x snapshot #333
Conversation
pjfanning
commented
Oct 18, 2023
•
edited
Loading
edited
- adjusts the tagNumber logic to treat build numbers without an RC or M tag as newer than ones that have them
- example
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am already testing this locally (and yes there is a regression in 1.0.x, I will make a revert commit), have one comment.
@pjfanning Do you want to get this over the finish line? I am happy with the change, just need want to change from I can also update the PR branch myself if you have time constraints. |
I've committed a change to call it |
@pjfanning Also need to add it to the matrix at https://github.com/apache/incubator-pekko-http/blob/17da94039e5b63d2be8f73cfac673e2a6f8517ca/.github/workflows/nightly.yml#L18 if you want the tests to actually run it. |
@@ -114,11 +116,12 @@ object PekkoDependency { | |||
ep.toInt, | |||
maj.toInt, | |||
min.toInt, | |||
Option(tagNumber).map(_.toInt), | |||
Option(tagNumber).map(_.toInt).getOrElse(Integer.MAX_VALUE), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why was this change needed? Is that part of
adjusts the tagNumber logic to treat build numbers without an RC or M tag as newer than ones that have then?
Don't see how using Integer.MAX_VALUE
is correct for what its doing (i.e. testing against latest found snapshot)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes - this is related to adjusts the tagNumber logic to treat build numbers without an RC or M tag as newer than ones that have them
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, but how is Integer.MAX_VALUE
going to provide a correct value here, or am I missing something? Is it just some sentinel value that will get ignored later (if so add a comment because logic/reasoning behind it is unclear).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh nvm, its for ordering and not the actual value. @pjfanning Can you just add a comment explaining that its there to fix ordering and then ill approve PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The values are used only in sorting.
-RC1-
will eval as 1- no
-RC
or-M
will now eval as MAX-INT - MAX-INT > 1 so sorting will treat non-RC/non-milestone releases as newer
Old logic:
-RC1-
will eval asSome(1)
- no
-RC
or-M
will eval asNone
None
<Some(1)
so sorting will treat non-RC/non-milestone releases as older
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Understood, just add a comment in the code quickly explaining this because on first glance its misleading.
I found something else, i.e. #333 (comment) . Also PR needs to be rebased/merge conflict against main since there are conflicts. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm, lets see how this runs
@pjfanning Good news its working, i.e. you can check the latest run at https://github.com/apache/incubator-pekko-http/actions/runs/6687481949 and to further confirm if you check the job at https://github.com/apache/incubator-pekko-http/actions/runs/6687481949/job/18168181064 you can see its picking up the latest
|
* allow test with pekko 1.0.x snapshot * Update PekkoDependency.scala * Update PekkoDependency.scala * rename config value to `1.0.x` * Update nightly.yml to include 1.0.x run * Update PekkoDependency.scala