Tool path is changing with minor versions

[matkoch]

From 5.1.2 to 5.1.3 the tool path was changed from netcoreapp3.0 to netcoreapp3.1. This makes it very unreliable to integrate GitVersion in other tooling, and it doesn’t follow semantic versioning, which I thought was the idea here.

[GeorgDangl]

Yeah, I agree here. Especially when using scripted builds, you often have to rely on the tools being available at predictable paths. Changing them between patch or minor versions leads to many breaking builds😊

[BlowaXD]

Agree, needed \o/

[matkoch]

@arturcic just a heads up, this is currently the highest voted issue

[matkoch]

@arturcic @asbjornu could you please give some feedback on this?

[arturcic]

@matkoch I agree that it was unfortunate to release the version under 5.1.3, maybe it made more sense 5.2.0 or similar. But the reason we released it with that version is that it was a mainly bugfix version, with small improvement and documentation. We also changed the .net core target as it was at the time released.

With the next version we'll try to include in the release notes the dependencies that were upgraded including .net core version.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs. Thank you for your contributions.

[matkoch]

@arturcic why not increase the major version, which would indicate breaking changes? From 5.1.3 to 5.2.0 the same thing happened again. GitVersion.dll to gitversion.dll, which fails on UNIX systems.

[arturcic]

Well I agree, maybe it was unfortunate the change, we renamed that to be consistent, and the change is made for integration tests. I would argue about the major change, as it's not a semnificant change in terms of functionality that's why it's a minor, not a major version change, we keep the major version for semnificant changes.

[arturcic]

So our versioning is based on the functional changes, not on the deliverables

[asbjornu]

What is versioned in GitVersion is its external APIs, which are the command line, the configuration file and the MSBuild task. When they change, a major increment is warranted. Everything else should be safe to change without breaking anything, but as with everything there are edge cases that could be argued either way. I hope there won't be more such edge cases before we do a major refactor for v6, though. Then you can expect everything to break. 😄

[stale]

This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs. Thank you for your contributions.