Skip to content

chore(coderd): extract api version validation to util package #11407

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

Merged
merged 3 commits into from
Jan 5, 2024

Conversation

johnstcn
Copy link
Member

@johnstcn johnstcn commented Jan 4, 2024

Extracts API version logic to a util package.

@johnstcn johnstcn requested a review from spikecurtis January 4, 2024 13:25
@johnstcn johnstcn self-assigned this Jan 4, 2024
Comment on lines 19 to 22
type APIVersion struct {
supportedMajors []int
supportedMinor int
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this mean if you do

{
	supportedMajors: []int{1,2}
	supportedMinor : 2
}

That v2.1 is not supported? Because the minor only supports 1 args, so all majors must be >= minor?

Feels odd because you could say support, v1.8 and v2.0, but in this function you cannot do that without supporting v1.0

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I agree. We may need to change this logic when supporting multiple minor versions. This is just a refactor though and I don't want to change the existing logic, just move it around.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, if you support majors {1,2} and minor 2, then you support 2.2, 2.1, 2.0 and 1.x

The minor support only applies to the highest major version.

That's because of the rules we have for how we bump major and minor versions.

If we make an API change that is back compatible, we bump the minor version.

If we make an API change that is non back compatible, we go to a new major version, and, ideally, keep support for the old major version for some time after. The old APIs we continue to support are feature-frozen, so we don't care about their minor versions any longer.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, that makes sense. Thanks for clarifying! I added the above to the doc comment for Validate().


func (v *APIVersion) Validate(version string) error {
if len(v.supportedMajors) == 0 {
return xerrors.Errorf("developer error: SupportedMajors is empty")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do this error checking on creation

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Modified function signature to make this impossible.


func TestAPIVersionValidate(t *testing.T) {
// Given
v := apiversion.New([]int{2, 1}, 0)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

since this is now abstract, set the minor to 1 so you can also test that it works for minor < supportedMinor

additionalMajors []int
}

func (v *APIVersion) WithBackwardCompat(majs ...int) *APIVersion {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Love this.

@johnstcn johnstcn merged commit 4d2fe26 into main Jan 5, 2024
@johnstcn johnstcn deleted the cj/util-apiversion branch January 5, 2024 10:22
@github-actions github-actions bot locked and limited conversation to collaborators Jan 5, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants