Arcade: Version scheme that fit small app

[wli3]

Our current version scheme does not fit for small app. dotnet suggest for example and likely many global tools.

The current scheme does not support automatic release version bump for every build. For small repo or repo with good test coverage, this is very likely the case. When automated test passed it should be good to go (there is no manual QA need or resource). Plus when it is an application instead of a library, assemblyversion can be bumped all the time.

[tmat]

Proposal

Allow projects to opt-in to _release only_ versioning by setting property ReleaseOnlyVersioning to true. If the property is set the assembly, file and package versions are calculated as follows:

• AssemblyVersion := MAJOR.MINOR.BUILD_NUMBER_HI.BUILD_NUMBER_LOW
• FileVersion := AssemblyVersion
• PackageVersion := MAJOR.MINOR.BUILD_NUMBER

where

• R is the number of builds the build definition started on day YY/MM/DD
• SHORT_DATE := YY * 1000 + MM * 50 + DD
• BUILD_NUMBER := (SHORT_DATE- BASE_DATE) * 100 + R
• BUILD_NUMBER_HI := BUILD_NUMBER / 50000
• BUILD_NUMBER_LOW := BUILD_NUMBER % 50000
• BASE_DATE := 19000

Note: SHORT_DATE is a concept used by the versioning scheme we already use.

Example for 5th build today (2019/3/14):

• AssemblyVersion = FileVersion = 3.0.0.16405
• PackageVersion = 3.0.16405

Example for 1st build on (2025/12/29):

• AssemblyVersion = FileVersion = 8.0.13.12901
• PackageVersion = 8.0.662901

[nguerrera]

For build tasks, I want that AssemblyVersion and FileVersion, but I don't necessarily want to make every package build stable. Can we decouple those two requirements/options?

[dougbu]

I'm still getting up to speed here and am wondering:

• How will / should this affect aspnet/AspNetCore, a repo that doesn't use the Arcade SDK?
• Does any of this affect our existing patch branches i.e. release/2.1 and release/2.2?

FYI I think this proposal matches what ASP.NET does in our release/2.x branches e.g. https://github.com/aspnet/Extensions/blob/release/2.1/version.props#L13-L27

[tmat]

@dougbu This does not not change the Core versioning scheme used by default and also implemented in the props file you mention. This is a versioning method of assembly, file and package versions that is only applicable to global tools and build tasks.

I don't think it affects 2.x at all. It's just a new method that will be available for repos that subcribed to the latest Arcade.

[tmat]

Can we decouple those two requirements/options?

Yes, let's do that.

How about properties:
AutoGenerateAssemblyVersion and ReleaseOnlyPackageVersioning, both true by default when PackAsTool is true.

[nguerrera]

A default on PackAsTool may break existing tools. Maybe this should just be recommended approach for tools.

[tmat]

OK, we can start with not defaulting for global tools.

[nguerrera]

Example for 5th build today (2019/3/14):

AssemblyVersion = FileVersion = PackageVersion = 3.0.0.16405

This looks incorrect. The package version should be distinct in this case too and shouldn't have 4 parts.

[tmat]

The package version should be distinct in this case too and shouldn't have 4 parts.

Yes. Updated.

[nguerrera]

I think BASE_DATE should be configurable and default to 190000. This way folks can set it to today's date when they bump major or minor version if they are concerned by the aesthetics of release package versions with many digits.

[tmat]

Yes, we can make BASE_DATE configurable.

[nguerrera]

OK, LGTM :)

[markwilkie]

@wli3 - is this something you're expecting my team to submit a PR for or were you planning to?

[tmat]

@markwilkie We need an approval to use this kind of package versioning first.

[markwilkie]

I thought we got one already? (there was an email a while ago from Andrew Hall) @KathleenDollard - can you confirm (or not?)

[markwilkie]

Pinging @KathleenDollard in email.

[markwilkie]

I got confirmation on another thread with @KathleenDollard that the PM org is fine with this proposal going forward.

[markwilkie]

@wli3 - is this something you're expecting my team to submit a PR for or were you planning to?

[tmat]

Looking into this.

[tmat]

@nguerrera

For build tasks, I want that AssemblyVersion and FileVersion, but I don't necessarily want to make every package build stable. Can we decouple those two requirements/options?

I think we can use already existing property PreReleaseVersionLabel - if the project sets it to empty it will produce release-only version - obviously. Currently repos set the property in eng/Versions.props file, which they can still do. Project building a global tool would set <PreReleaseVersionLabel/>.

[tmat]

A default on PackAsTool may break existing tools. Maybe this should just be recommended approach for tools.

How about reporting an error if PreReleaseVersionLabel is empty and PackAsTool not true?