Skip to content
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

RFC: IR format versioning #258

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Conversation

iamdanfox
Copy link
Contributor

@iamdanfox iamdanfox commented Mar 18, 2019

Rendered

Before this PR

We're somewhat blocked on all the issues tagged 'IR change' and also #227 because the mechanism for actually making an IR change is undefined.

After this PR

==COMMIT_MSG==
RFC: IR format versioning recommends single-digit scheme
==COMMIT_MSG==

This RFC just tackles the first problem for an IR rev - will follow up with a separate RFC to discuss lossless upgrading/downgrading etc.

Possible downsides?

A bad decision about IR versioning could result in the conjure ecosystem becoming confusing to use / contribute to, or alternatively introduce excessive overhead and unintentionally hamper development.

The upside is that this RFC can always be superseded if significant problems arise.

@iamdanfox iamdanfox requested a review from a team as a code owner March 18, 2019 12:56
**Producers** | Don't care (minor rev) | Breaking (major rev)
**Consumers** | Breaking (major rev) | Don't care (minor rev)

Producers don't care about additive changes to the IR because they can keep taking upgrades whether the new features are relevant to them or not. Producers do care about restrictive changes to the IR as this could potentially make their current API definitions invalid, thereby even . This suggests additive changes should increment minor, and restrictive should increment major.
Copy link
Contributor

Choose a reason for hiding this comment

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

thereby even .

I think we're missing some words

@carterkozak
Copy link
Contributor

This looks sane to me. It reinforces the decision to support a single integer version field, and I don't see serious downsides. If we were to fundamentally change the meaning of the IR we could also rename the version, causing all existing non-compliant parsers/generators to fail as we would expect in alternative version proposals.

@stale
Copy link

stale bot commented Oct 15, 2019

This PR has been automatically marked as stale because it has not been touched in the last 14 days. If you'd like to keep it open, please leave a comment or add the 'long-lived' label, otherwise it'll be closed in 7 days.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants