Strategies for assembly versioning

[nulltoken]

Current state of affairs

Currently asmversion is set to major.minor.0.0 for the purpose of this discussion lets call this strategy MajorMinor

Other potential strategies

• MajorOnly= `major.0.0.0``
• Strict= major.minor.patch.0
• None = `1.0.0.0``

Proposed changes

In order to relieve some of the pain with strongnaming until we can remove it we (NServiceBus) has decided to only put the major into our asm version to avoid asmredirects for minor + patch updates. Ie we're applying the MajorOnlystrategy from above. I propose that we add at least that one to GitVersion

Defaults

Should we keep the current strategy as the default?

The way I see it the MajorMinor is somewhat between all the others and if you follow SemVer AND is strongnamed I argue that MajorOnlyis more appropriate.

For non strongnamed projects the obvious strategy would be the Strict since its non lossy. Could we in anyway detect this and adjust accordingly?

If we can't detect perhaps Strictis the best default and then strongnamed projects can override depending if they follow SemVer or not?

[andreasohlund]

cc @SimonCropp @JakeGinnivan @nulltoken

[GeertvanHorrik]

I think strict must be the default.

[nulltoken]

I've started to work on this.

[nulltoken]

I've pushed up two commits to get some early feedback.

Main changes:

• Replaced the SignAssembly Task property in favor of AssemblyVersioningScheme
• Used MinorMinorPatch instead of Strict

[nulltoken]

Hmmm. Build failed.

I'm a bit puzzled by the error message:

Test(s) failed. System.Exception : Approvals is not set up to use your test framework.
It currently supports [NUnit, MsTest, MbUnit, xUnit.net, xUnit.extensions, Machine.Specifications (MSpec)]
To add one use ApprovalTests.StackTraceParsers.StackTraceParser.AddParser() method to add implementation of ApprovalTests.StackTraceParsers.IStackTraceParser with support for your testing framework.
To learn how to implement one see http://blog.approvaltests.com/2012/01/creating-namers.html

@SimonCropp Could you please give me a hand here? Previous commit was also relying on Approvals and passed.

[SimonCropp]

@nulltoken can u try putting debug-info to full on the release build of the test project? if that doesnt work (and u r comfortable with the current state) merge it and I will fix it in dev

[JakeGinnivan]

This error can happen for release builds. Without the source location approval tests doesn't work. @SimonCropp's fix should work

[JakeGinnivan]

I have also had to attribute my test method with no-inlining which also has fixed this issue for me in the past

[andreasohlund]

Are we all good with strict being the default?

[JakeGinnivan]

Yep, strict is good.

The issue with not being strict by default is it actually sucks for the people that use strong naming for real reasons (like simon)

[nulltoken]

Ok. I more or less managed to have the tests pass (thanks to @SimonCropp and @JakeGinnivan help).

Now there's a different kind of failure:

[11:31:55]Step 5/5: xUnit (Command Line)
[11:31:56][Step 5/5] Step xUnit (Command Line) failed

Any idea? Once this is solved I'll clean up the history from my attempts.

[JakeGinnivan]

This is my fault. I can't look into it for now. Just disable that build step for now until I can look into it

[nulltoken]

@JakeGinnivan Disabling the last step fixed the issue. Thanks!

[nulltoken]

All good now.

• Tests are passing
• Commit history cleaned up

[andreasohlund]

Looks good to me!

[andreasohlund]

@nulltoken I just saw that MajorMinor is missing. Was that removed on purpose?
cc @yvesgoeleven

[nulltoken]

@nulltoken I just saw that MajorMinor is missing. Was that removed on purpose?

Duh. That's a mistake. 😳

I'll send a PR this evening along with some tests to cover this assembly versionning scheme.

__shamefully crawling back under my rock**

[andreasohlund]

No worries!