For maintainer sanity, we version ReactiveUI and package as a pinned group - all packages in a release will always be the same version and only work with that version which makes it impossible for a consumer to run into situations where they use
7.0.0. Additionally all assemblies share the same CommonAssemblyInfo.cs which is updated just before compile time by the build infrastructure.
We have three different workflows which control how ReactiveUI is versioned.
Builds from the
develop branch have a suffix of
alpha so that they are sorted higher than release builds which provides the team the ability to manually publish development builds to NuGet as pre-releases if they so desire.
GitVersion is configured in Continuous Deployment mode which automatically increments the version for you.
Pull Request Builds
Builds from pull-requests have a suffix of
pullrequest$GitHubIssueNumber and are not automatically published to NuGet or MyGet but the packages are available for download from AppVeyor which allows the team to test the unit of change without merging into
Builds from the
master branch do not have a suffix and GitVersion is configured in ContinuousDelivery mode. If the current commit is tagged, the version in the tag overrides the automatic versioning strategies.
- remove public API surface area
- drop support for a platform
- adopt a newer MAJOR version of an existing dependency
- disable a compatibility quirk off by default
- add public API surface area
- add new behavior
- adopt a newer version of an existing dependency
- introduce a new dependency
- any other change (not otherwise captured)
- never, unless you really stuff something up.