[Bug] Assembly Informational Version custumization ignored

[fedebn]

Using GitVersion.yml to set custumized Assembly Informational Version, any charater used to separate version number from ShortSha is ignored and substitued with -.

Expected Behavior

verified with version 5.1.3

assembly-informational-format: '{Major}.{Minor}.{Patch}_{ShortSha}'

1.2.3_856daf9

Actual Behavior

verified with version 5.2.4

assembly-informational-format: '{Major}.{Minor}.{Patch}_{ShortSha}'

1.2.3-856daf9

[asbjornu]

This change might have been introduced in #2014. Perhaps we need a more fine-grained replacement strategy here. 🤔

[fedebn]

I don't know which charaters are not allowed in SemVer, but i think alphanumeric charaters are not allowed, but some symbols like '-' '_' '.' '|' are allowed, right?

[asbjornu]

The regex of characters allowed in a SemVer 2.0 compatible pre-release label is [0-9A-Za-z-]. So I suppose the question here is: Should we allow InformationalVersion to be incompatible with SemVer?

[fedebn]

If the scope of GitVersion is to use InformationalVersion as SemVer, if think this bug can be rejected

[asbjornu]

Well, no, it's the other way around. GitVersion generates a SemVer 2.0 compatible version number, then provides many different serializations and formats of this version numbers targeting different environments.

Since AssemblyInformationalVersionAttribute allows for a larger set of characters than SemVer 2.0, I think it's natural to think that assembly-informational-format should only affect AssemblyInformationalVersionAttribute and thus allow characters not allowed in SemVer 2.0. I'm just not quite sure yet how to implement it.

[fedebn]

So, i'm not sure, but we can think about a warning at compile time if AssemblyInformationalVersionAttribute isn't comply with SemVer 2.0.

[asbjornu]

Providing the warning at compile time is going to be difficult, but we could log a warning statement during execution.

[NeilMacMullen]

Speaking only as a user, but we wish to use AssemblyInformationVersionAttribute as a way of holding more detailed build information than can be obtained from the SemVer format. (For example, the date of the commit, name of build-machine/user, what the user ate for breakfast etc...) By all means, have a way of stuffing a SemVer-compatible string into this field but, please also allow for those of us who want to include arbitrary information. I'm aware we could create a custom attribute ourselves but since gitversion already does 95% of what we want in setting up the attributes, it seems a shame not to also use it for customised info.

The 'flattening' of characters into hyphens is particularly annoying when trying to treat the information field as structured data since dates and branch-names also regularly contain hyphens, a custom format such as
assembly-informational-format: '{MajorMinorPatch} {CommitDate} {ShortSha} {BranchName} {env:USERNAME} {env:BREAKFAST}'
can turn into

"1.7.6-2020-05-18-e1bbd7e-bug-fix-345-neilm-fried-eggs"
which means extraction of fields is much more awkward.

[asbjornu]

Sure, if someone provides a pull request that doesn't restrict the format of AssemblyInformationVersionAttribute with tests, it will be merged. As none of the maintainers of GitVersion has a need for this feature, it is very unlikely any of us are going to spend our free time implementing this, sorry.

[NeilMacMullen]

Seems reasonable - just wanted to check there is no underlying design-philosophy that means that such a PR would be rejected?

[asbjornu]

No, as I wrote in #2199 (comment), the current behavior is just a conservative default. We might want to allow the current behavior to continue as is and figure out a backwards compatible way to implement this, though. One way is to introduce a configuration value, but we may also look at how this can be solved better with a breaking change in the upcoming version 6 of GitVersion.

Ideas are welcome to be discussed here before a pull request is submitted.

[LazaroOnline]

I created a pull request for this as I also need this feature:
#2341