Versioning, BeatPulse, UI and liveness Packages...

[unaizorrilla]

At this moment, each BeatPulse Liveness Package, BeatPulse, UI and trackers have specific version numbers for each package. As a matter of fact between BeatPulse, UI, liveness and trackers exist a strong relationship due the contract of LivenessResult.

The strategy we have now does not seem adequate because there is no way to know which version of UI is valid for a specific version of the BeatPulse, e.g.

I'd like to know if anyone has any idea how best to address this problem?

[x2764tech]

Coming as an outsider to the project, so probably don't understand the full implications, but the usual solution is Semantic Versioning. This is how dotnet core does this.

NuGet supports this - allowing version ranges for package references (either 6.*, or [6,7) - the former being a bit more comprehensible to me).

So, all versions 1.x would be deemed to be compatible, but a breaking change would mean a major version bump. It takes a bit of co-ordination across packages, but seeing that they're all in the same repository, referencing a single file with the major version in, and then bumping that after a release would seem to make sense.

[unaizorrilla]

Hi @x2764tech

Thanks for the link reference and for the comments, I know semver and is on the solution right know.

[x2764tech]

You could also use a Directory.Build.props to keep them in sync (see https://www.thomaslevesque.com/2017/09/18/common-msbuild-properties-and-items-with-directory-build-props/ and https://docs.microsoft.com/en-us/visualstudio/msbuild/customize-your-build#directorybuildprops-and-directorybuildtargets)

[unaizorrilla]

Hi @x2764tech

This project use Directory.Build.props from the scratch!