search

opentracing / opentracing-csharp

OpenTracing API for C# (.NET). 🛑 This library is DEPRECATED! https://github.com/opentracing/specification/issues/163
http://opentracing.io
Apache License 2.0
516 stars 73 forks source link

Calculate version number based on environment/github tag #100

Closed cwe1ss closed 6 years ago

cwe1ss commented 6 years ago

I'd like to do a RC-release with the upcoming changes. However, this is not possible with the current build script as it will always do a VersionSuffix-less release if there's a git tag.

With these changes, I introduced a separate version.props file that now contains all of the version number logic (similar to ASP.NET Core projects). I'm copying the description with the new logic from that file here for further details:

These settings ensure that we don't have to manually increment version numbers after every release!

If there's an AppVeyor tag, we always build with that tag name as the Version. This overwrites any VersionPrefix and VersionSuffix so the tag MUST have a SemVer-compatible name!

Any non-official (non-tagged) build uses a fixed (high) VersionPrefix and an incrementing suffix. This ensures that people who want to reference a package from a regular build can do so by specifying the complete version (e.g. 99.99.99-b0014 or 99.99.99-*) which will always be higher than any official release and therefore will always take priority.

The thing to discuss might be the "99.99.99" version for local / regular CI builds. I have this trick from the XUnit project. The advantage with this is that we will never have to bump the version manually again (which is really easy to forget).

cwe1ss commented 6 years ago

I will merge this now so that I can create the RC release. Please comment here (if that's possible), in #92 or create a new issue if you have any concerns with this.