status: LATEST should be of the same type as VERSION#1515
status: LATEST should be of the same type as VERSION#1515sdboyer merged 2 commits intogolang:masterfrom
Conversation
This change modifies the LATEST field in status from always being a revision to the same type as of the VERSION field. If VERSION is a semver version, the LATEST would have the latest semver version of the project constrained by the effective constraint. If VERSION is a branch version, the LATEST would have the latest revision of that branch.
f0c97b0 to
7ed3aa2
Compare
|
So there's good news and bad news. 👍 The good news is that everyone that needs to sign a CLA (the pull request submitter and all commit authors) have done so. Everything is all good there. 😕 The bad news is that it appears that one or more commits were authored by someone other than the pull request submitter. We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that here in the pull request. Note to project maintainer: This is a terminal state, meaning the |
| // Latest should be of the same type as the Version. | ||
| if bs.Version.Type() == gps.IsSemver { | ||
| bs.Latest = v | ||
| } else { |
There was a problem hiding this comment.
This doesn't account for plain versions - those will still show up with a rev. Can deal with it later, though.
There was a problem hiding this comment.
But we enter this version's updatability check block only for non-rev and non-plain version. LATEST for plain version would be empty. I think that's the right behavior.
What does this do / why do we need it?
This change modifies the LATEST field in status from always being a
revision to the same type as of the VERSION field.
If VERSION is a semver version, the LATEST would have the latest semver
version of the project constrained by the effective constraint.
If VERSION is a branch version, the LATEST would have the latest
revision of that branch.
More precise tests can be added for this change after #1498 .
What should your reviewer look out for in this PR?
Implementation details and the change in existing tests.
Do you need help or clarification on anything?
No.
Which issue(s) does this PR fix?
None.