Non-semantic version mode?

[JakeGinnivan]

Sometimes we just want our versioning to work and we don't need semantic versioning.

Maybe we should add a /classic switch which makes NuGetVersion and other common versions switch with a {major}.{minor}.{patch}.{commit-count} format.

Similar to the way develop works now, but makes it opt in for any branch

[seankearney]

I think this proposed switch when used in combination with /updateassemblyinfo makes things a lot easier for simple versioning. Set the AssemblyVersion and AssemblyFileVersion attributes with {major}.{minor}.{patch}.{commit-count} and keep AssemblyInformationalVersion attribute with full meta would be great.

[andreasohlund]

+1

Not sure about the classic how about non-semver |
continuous-delivery-mode or something like that?

On Thu, Aug 14, 2014 at 10:26 PM, Sean Kearney [email protected]
wrote:

I think this proposed switch when used in combination with
/updateassemblyinfo makes things a lot easier for simple versioning. Set
the AssemblyVersion and AssemblyFileVersion attributes with
{major}.{minor}.{patch}.{commit-count} and keep
AssemblyInformationalVersion attribute with full meta would be great.

—
Reply to this email directly or view it on GitHub
#242 (comment)
.

[MicahZoltu]

Something to consider is that the CLR assembly loader treats major/minor versions differently than build/revision versions. In particular, if 1.2.3.0 of AssemblyA is loaded into memory and an AssemblyB references something in AssemblyA 1.2.4.0, the CLR will not attempt to load another copy of AssemblyA into memory. It will see that 1.2.3.0 is loaded and believe that that is good enough and attempt to use it.

I'm not sure whether this will influence this feature, but if the goal is to make a very simple non-semantic versioning system for users then it may be worth considering only having major/minor versions used so that confusing/undesirable behavior doesn't occur for these simple-case users.

[JakeGinnivan]

@Zoltu I think if the user is in a situation where they have multiple copies of a single assembly available for the CLR to resolve they are probably in a situation where they should be using strong naming?

It would also make the logic very different. Promoting the ClassicVersion variable to the NuGet variable is not too bad.

[MicahZoltu]

I don't believe strong naming will help in this situation. Most likely, the same signing key would be used for both version 1.2.3.4 and 1.2.3.5 so the CLR will accept either of them. That being said, I am not really that convinced that this situation is a real problem for most people. I just wanted to mention it to make sure it was thought about. Currently, my stuff uses major.minor.patch for versioning and I don't worry about conflicts, but my projects tend to be very small.

[hmemcpy]

+1 for "classic" mode.

Our product is a VS extension with a typical installer (msi). We used {major}.{minor}.{patch}.{somenumber_based_on_the_current_date} for both AssemblyFileVersion and AssemblyVersion.
This sort of works for us, and we'd like to keep using this "scheme", so the ClassicVersion format works very well for us. I'd love to pass an additional /classic switch, so the /update command would use ClassicVersion instead.

[JakeGinnivan]

If we fix #277 then we should be able to close this

[JakeGinnivan]

So, #302 updates the AssemblySemVer variable and adds AssemblyFileSemVer variable to listen to the AssemblyVersioningScheme configuration option in config.

It does not update the NuGet version etc. Does this work for everyone?

[JakeGinnivan]

This mean in the GitVersionConfig.yaml file you can add

AssemblyVersioningScheme: MajorMinorPatchBuildmetadata

Then AssemblySemVer and AssemblyFileSemVer will be {major}.{minor}.{patch}.{buildmetadata}