Update Base Version in azure-pipelines.yml

[twsl]

Description of Change

This is a quick and dirty fix for the issue regarding the nightly versions by raising the semantic base version.

Linked Issues

• Fixes [BUG] Wrong version for Nightly builds #909

PR Checklist

• Has a linked Issue, and the Issue has been approved(bug) or Championed (feature/proposal)
• Has tests (if omitted, state reason in description)
• Has samples (if omitted, state reason in description)
• Rebased on top of main at time of PR
• Changes adhere to coding standard
• Documentation created or updated: https://github.com/MicrosoftDocs/CommunityToolkit/pull/XYZ

Additional information

[net-foundation-cla]

All CLA requirements met.

[brminnick]

Is there a way to automatically set its version number based on the version number of the latest release?

Otherwise, we will have the same problem after we release v4.0.0.

[bijington]

git describe might get you some of the way there...

https://git-scm.com/docs/git-describe

Sadly I don't know how we would determine the type of change and ultimately the change in version component.

The best long term solution is to use a tool like GitVersion that just does it for us

[VladislavAntonyuk]

I think we can set the version number to 99.99.99.99, in that case it will always be a latest version, if user wants to use nightly builds

[brminnick]

I think we can set the version number to 99.99.99.99

Works for me!

[twsl]

as proposed in the discussion, ideally something like GitVersion would be used to automatically calculate the semver. Just using the same version number for everything might cause other problems in the future but could work for now

[VladislavAntonyuk]

as our next release is 4.0.0, let's for now use 4.1.0 and see how it works.
Ideally, we can use GitVersion as suggested.
I do not recommend use 99.0.0.00 in case somebody limits the latest version (>3.1.0 && <5.0.0)

[twsl]

Can someone else approve this so it gets merged?

[VladislavAntonyuk]

@brminnick, @jfversluis are you ok with the changes?

[brminnick]

If this is not urgent, I prefer that we implement a permanent solution that references the latest release number and works for both CommunityToolkit.Maui and CommunityToolkit.Maui.MediaElement.

This is a pretty low-effort PR that doesn't actually fix anything; it just delays the problem and creates more work for us in the future (we'll have to open a PR to bump this version number after every release).

[VladislavAntonyuk]

@twsl Could you please investigate how we can use GitVersion solution?

[twsl]

I can try, the issue with that is that I cannot test the azure pipelines locally

[VladislavAntonyuk]

@twsl don't worry about it. If the build passes, you can find the version number in the GitHub actions result:

[bijington]

@twsl are you happy looking into the GitVersion approach? If not then I would be happy to help out

[twsl]

@bijington Feel free to tackle this. I did a quick test and just adding the nuget to the project causes issues and fails to build. Not sure if this requires GitTools/GitVersion#3334. Adding the azure pipelines task could also be a solution tho

[bijington]

@bijington Feel free to tackle this. I did a quick test and just adding the nuget to the project causes issues and fails to build. Not sure if this requires GitTools/GitVersion#3334. Adding the azure pipelines task could also be a solution tho

Thanks for having a look. I'll look into that issue and hope that we can workaround it

[twsl]

@dotnet-policy-service agree

[bijington]

@jfversluis this reminds me we need to have a chat about GitVersion