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

feat: Introduce featuresAvailable into gen.lock #60

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

Conversation

bflad
Copy link
Member

@bflad bflad commented Oct 17, 2024

Reference: https://linear.app/speakeasy/issue/SPE-4333/regenerate-ast-on-changes-to-availablefeatures

This change adds a new mapping of target-available feature versions to the gen.lock file, to augment the currently used target feature versions. This would be used to detect changes to the target itself, such as new features, that should always cause target regeneration instead of potentially loading a cached AST.

Alternatively, this change could be avoided by having an overall, singular "target version" for tracking when any change is made to a target, however the overhead of managing that more global version in addition to the individual feature versions would be quite cumbersome.

Alternatively, this change could be avoided by using the existing features field to store all feature versions instead of only used features, but having the ability to inspect used features helps guide product and customer success decisions. It also would break existing niceties, such as only showing changelog entries relevant for used features.

Reference: https://linear.app/speakeasy/issue/SPE-4333/regenerate-ast-on-changes-to-availablefeatures

This change adds a new mapping of target-available feature versions to the `gen.lock` file, to augment the currently used target feature versions. This would be used to detect changes to the target itself, such as new features, that should always cause target regeneration instead of potentially loading a cached AST.

Alternatively, this change could be avoided by having an overall, singular "target version" for tracking when any change is made to a target, however the overhead of managing that more global version in addition to the individual feature versions would be quite cumbersome.

Alternatively, this change could be avoided by using the existing features field to store all feature versions instead of only used features, but having the ability to inspect used features helps guide product and customer success decisions. It also would break existing niceties, such as only showing changelog entries relevant for used features.
Copy link

linear bot commented Oct 17, 2024

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

Successfully merging this pull request may close these issues.

1 participant