Extend existing System.Version class or provide new one.

[comdiv]

Must support not just {Maj}.{Min}.{Rev}.{Bld} but be more smart and complex.
Assume prod-edition.1.2-rc1-rev:43abcd32
Expected:

1. System.Version.Parse should not fail
2. It splits version with all existed delimiters: ['prod','edition',1,2,rc1,rev,43abcd32] and provide all of them as Parts
3. It trys detect {Maj}.{Min}.{Rev}.{Bld} from numeric Parts - {1,2} here
4. It trys detect ProductName from all literal parts before first number
5. It has some logic (may be with Extension ) to determine production state of version (rc, beta, alpha, release, dev, src) and so on and apply them as tags or enumeration to Version instance

It can be very helpful for #15824 and for dealing with any package/ product versions. Additionally it add support to provide more complex version info for assemblies with Assembly(File)Version attribute.

[stephentoub]

There are many different forms a version beyond {Maj}.{Min}.{Rev}.{Bld} could take. The additional example you provide is just one form. I would expect that each form would need its own parser, and that's not something that should be baked in to corefx.

[comdiv]

No, read issue more detailed. I suggest provide string[] Parts that is independent from format

[stephentoub]

Then why not just use string.Split? You weren't just suggesting exposing a string[] Parts, you were suggesting additional heuristics on top of that, and I'm saying that I don't believe such heuristics should be codified into a type in corefx.

[davidfowl]

Agreed. Just use the nuget semantic version class https://github.com/NuGet/NuGet.Client/blob/dev/src/NuGet.Core/NuGet.Versioning/SemanticVersion.cs

[comdiv]

Not agree. Why we should use so strict version format for AssemblyVersion and so on. X.X.X.X is not so good format to think that it's standard. For now - assembly versions are distinct from that is applyed to other parts. For example numeric Revision is good for numbered VCS such SVN and not so good for hashed (git).
What about Split? we can answer this way about all things - why String.Length and not strlen(char*). Why WebClient.Download and not Socket.Connect(...) . It's about incapsulation - we see class Version. It not called as "Simple4NumberVersion". And it's not exactly that is's named.
Does split allow me to compare versions?
The only thing i aggree is that System.Version is not main problem that should be revised soon.

[stephentoub]

Is your request actually about being able to use a different versioning scheme for assemblies? That's a different issue. If you have a compelling reason for why that should be expanded, please feel free to open an issue in the coreclr repo about that.

But that's mostly separate from saying that Version as a class should support arbitrary versioning schemes. You gave one specific example that has some very specific characteristics: it uses -, ., and : as separators. What if someone has a versioning scheme where those are valid parts of individual pieces? A type for parsing and comparing this would need to know whether to treat those as separators or not, and the same goes for other charactes you didn't cite. What about casing... is case an important feature for comparisons? What if some version formats allow for strings in certain places but not others? And so on.

The point is that you're proposing taking an existing type that currently has very well-defined semantics and augmenting it with arbitrary heuristics around parsing arbitrary strings. Further, the existing Version class has semantics that would likely result in consuming code breaking if it applied such additional semantics, e.g. code that relies on version parsing failing in certain cases. And without a concrete specification for the formats supported, this does not belong in corefx.

If the Version class as is doesn't meet your needs, and if the type that @davidfowl suggested doesn't meet your needs, you're of course welcome and encouraged to write your own implementation that provides the exact behavior you want and put out a NuGet package so that others can consume your implementation. At that point it doesn't really matter that it's not in corefx, as others can use it just as easily.

Given all this, I'm going to close out this issue. But thank you for the suggestion and interest.