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

Ability to provide version to publish #828

Open
brian-mcnamara opened this issue May 14, 2024 · 6 comments
Open

Ability to provide version to publish #828

brian-mcnamara opened this issue May 14, 2024 · 6 comments

Comments

@brian-mcnamara
Copy link

We have a use case where we want to add CI/CD for internal feature development. As part of this, we want to allow developers developing features to publish "snapshot" versions for them to test in production. We also want to tie release builds to the commit they were built on.
Currently, it seems features have a hard requirement around semver versioning which makes this tricky for CI/CD to easily version. Ideally, we could call publish passing in the version to use which could be a short commit sha to use for the feature version.

Curious to hear if the semver requirement is needed or whether this can be relaxed to allow a version flag to be passed to publish to allow custom tagging/versioning of features.

Happy to submit a PR, but wanted to get some clarification around this use case before diving in.

@bamurtaugh
Copy link
Member

Thanks for opening! I'd be curious to get @samruddhikhandale and @joshspicer's thoughts here.

@samruddhikhandale
Copy link
Member

Hi 👋

Thanks for the detailed ask in here.

Curious to hear if the semver requirement is needed or whether this can be relaxed to allow a version flag to be passed to publish to allow custom tagging/versioning of features.

Features spec was mainly created with production use in mind. However, for your use case, where you want to publish "snapshot" versions tied to a specific commit for internal testing, semver might seem restrictive. One common approach to handle this scenario is to use pre-release versions as defined by semver. You can append a hyphen and an identifier to your version number (e.g., 1.0.0-abcdef1 where abcdef1 is the short commit SHA). This allows you to keep the benefits of semver while also tying the version to a specific commit.

Let us know if that ^ was helpful in your case.

@brian-mcnamara
Copy link
Author

Hey @samruddhikhandale , sorry for the delay, catching up from some time off. That actually would be perfect, would it make sense to have a flag as part of publish that allows us to publish the features postfixed with a dash and the provided value (which we could use to provide the short commit sha)?

Alternatively we could script a way to update the version to have that postfix, but this seems generic enough to be incorporated.

@samruddhikhandale
Copy link
Member

That actually would be perfect, would it make sense to have a flag as part of publish that allows us to publish the features postfixed with a dash and the provided value (which we could use to provide the short commit sha)?

I believe we currently allow publishing a postfix with dash versions, however, can you try and let us know if it's working?

@brian-mcnamara
Copy link
Author

That is correct, I'm checking if we can add an argument to the publish command line options to allow specifying the postfix. Such that the version specified in the feature json can be static, and the command line appends the postfix during build/publish in order to keep the CI simple (instead of creating logic to update the files before running publish)

@brian-mcnamara
Copy link
Author

@samruddhikhandale checking back, we're happy to implement the ability to provide a version postfix to the command line arguments as a PR, but want to confirm that is a reasonable thing to implement

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

No branches or pull requests

3 participants