Add ADR on how to address version priority #4750
Conversation
github-project-automation
bot
moved this to In Progress
in Azure Service Operator Roadmap
matthchr
left a comment
matthchr
left a comment
There was a problem hiding this comment.
Approved with some minor clarity comments
docs/hugo/content/design/ADR-2025-05-Version-Priority/_index.md
Outdated
Show resolved
Hide resolved
docs/hugo/content/design/ADR-2025-05-Version-Priority/_index.md
Outdated
Show resolved
Hide resolved
|
|
||
| A simple change to the format we use for resource versions would be to simplify the prefix used to just `v`, giving resource versions like this: | ||
|
|
||
| * `v20210201` |
There was a problem hiding this comment.
Another option is to do v<date>1 or v1<date> (we'd probably want v1<date> so that updated ASO schemas result in those versions all "winning"), which results in a somewhat awkward looking number but maintains all of the ordering guarantees we want.
Though, I suppose the argument could be made that if we ever want to make a big change like that, we could still do it and just introduce v1<date> at that time, and since 1<date> is larger than <date> it'll take precedence, and avoids us needing to commit to the awkward 1 now, only if we ever end up needing it?
I think I'm fine with that as the approach but it would be good to call out some of that logic in the ADR for future-us.
There was a problem hiding this comment.
Added, including discussion on why it's not a good idea.
docs/hugo/content/design/ADR-2025-05-Version-Priority/_index.md
Outdated
Show resolved
Hide resolved
github-project-automation
bot
moved this from In Progress
to Recently Completed
in Azure Service Operator Roadmap
matthchr
moved this from Recently Completed
to Ready for Release
in Azure Service Operator Roadmap
What this PR does
Captures offline discussion about how to address #4147 so that users don't get nasty surprises.
How does this PR make you feel?
Checklist