CODEWITHSUNDEEP
continuous-integrationnuget.net-assemblycontinuous-deploymentsemantic-versioning
Sleeper Smith
Sleeper Smith

Reputation: 3242

Semantic versioning and continuous deployment, conflicting idea in practice?

Some times the version information has to be embedded in the metadata of the output artifact. So, the version has to be decided at the build/compile time.

However, you can't call a version until you actually make a release in semantic versioning because the last digit has to be incremental.

E.g.

A release process has 6 steps. There are 2 builds coming through triggered from commit 1 and commit 2.

Before commit 1 finish the release process in step 6, you can't really determine what semantic commit 2/build 2 is going to be. If commit 1/build 1 fails, commit 2 / build 2 would be 1.0.0. If build 1 succeeds, build 2 would be 1.0.1.

If you are authoring nuget package or .net binaries, the version information would be already in the artifact itself and there's no way to change that.

Upvotes: 2

Views: 570

Answers (1)

Dan Cornilescu
Dan Cornilescu

Reputation: 39834

Does the incremental digit requirement as you describe it make sense?

Even if build 1 succeeds (thus validating v1.0.0 according to your description) you'd still not ship it if its result is DOA from the testing prospective (say the product keeps crashing).

So what would be the difference between v1.0.0 not deployed/shipped because it fails the build or because it's DOA? None as far as I can see.

I'd just drop that requirement and keep things simpler - each build has its own version based on the corresponding commit and some versions are not good (for whatever reason).

Upvotes: 1

Related Questions