All packages in repo get version bump for every commit, even irrelevant ones

We have multiple projects inside a repo for all of our shared code that we use to build Nuget packages from (one Nuget package per project). I just started using this project for versioning all of our packages and really liking it so far - thanks for the awesome work!

The one thing I’d like to improve is how to get the Git Height working well for multiple projects. Right now, if we make changes to one project (say 6 commits in one folder for the one project) then it will result in the version number being bumped up by 6 for all of our projects: This makes it hard to know when to update our project dependencies as it’s unclear whether it’s actually a new package or not.

Of course, this makes sense based on how the version is calculated, but I was wondering if there is a way to have this be based on the folder/project without having to move to separate git repos for each project. We currently have a version.json file per project so it would be neat if the git height could be calculated from the location of the version.json file down or something like that. Any suggestions on how to do this better?

[AArnott]

CALL FOR VOTE

Consider a situation of projects A and B, where A references B. B is changed. What should happen to A’s version?

Please thumbs up this particular message if and only if: A should experience a version bump.

Please thumbs down this particular message if you do not expect A to experience a version bump.

IMO, if B is a packaged project of its own, I can see an argument where A needn’t be incremented (although it means installing A will give you an older version of B). But if B is not a packaged project, it seems paramount that A’s version is incremented or else the change to B will never ship.

[herebebeasties]

I think it should be opt-in, not opt-out, as it’s bound to result in version numbers going backwards when added, otherwise.

Newer SDK-style projects probably save us a bit, in that at least they don’t thrash their file contents so much.

Totally agree on the caching aspect, as I mentioned - it needs to be fast enough full stop. To that end, I don’t think doing a design-time build is the way to go. I’m aware of all the subtleties of not doing that (Directory.build.props files that might themselves have imports driven by variables or whatever other clever people are using) but there are subtleties the other way around, too.

For example, what if a project reference is conditionally included based on target framework? You could end up with a different (divergent) version number per framework, which doesn’t sound like what you’d want. Better to just treat all transitive imports/refs as if they’re unconditional IMO.

My team has some experience here, so we’ll look into it all a bit further and let you know.