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

prepare-release command does not update multiple version.jsons #872

Open
BenjaminBest opened this issue Dec 9, 2022 · 2 comments
Open

Comments

@BenjaminBest
Copy link

BenjaminBest commented Dec 9, 2022

We are currently evaluating Nerdbank.GitVersioning in the context of a mono repository. We have multiple features in that repository which need individual versioning.

To accomplish that, we used a global version.json and multiple feature version.json files with path filters and using "nbgv cloud" in an Azure Devops pipeline works very well: It detects changes for each feature and increments the version only of that feature which was touched, but the "nbgv prepare-release" does not.

There are 2 issues with "prepare-release" (for us):

  • First it creates a direct commit to master which is not allowed due to branch policies (this can be fixed, by turning off the policies, even tho it's not nice)
  • Second, and for this we could not found a workround, it does only touch and increase to the next minor version for the global (root-folder) version.json. Even tho Nerdbank.GitVersioning seems to support multiple version.json files (even with inheritance) this command does not update versions for all version.json in the repository.

Is there any workround or can this feature be added? Many thanks.

@AArnott
Copy link
Collaborator

AArnott commented Dec 9, 2022

Given a multi-version.json repo can have multiple divergent versions going at once, how would you expect it to behave when you issue prepare-release? Suppose one version.json was set to 1.2-beta while another was set to 2.0. When you run prepare-release, how would each of these change?

It's easy enough to reason about when it operates only on the applicable one given the working directory, because the user expects the 'current' one to increment. But does the user really expect when they are in the 1.2-beta directory one to also increment the 2.0 stable directory to 2.1-beta?

@AArnott
Copy link
Collaborator

AArnott commented Dec 9, 2022

Regarding the 'direct commit to master', you can always push that local branch change as a different branch and send a PR, can't you?

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

2 participants