Fixing Default API Version for Build API in TFS 2018

[SebastianSchuetze]

Adjusting default API version for the Build API in TFS 2018 as documented in the issue #78.

The default version is changed from 3.0 to 3.2.

This has never been adjusted.

[SebastianSchuetze]

@DarqueWarrior I can't really test this as I have not TFS 2018. How should we do that?

[DarqueWarrior]

TFS 2018 should be 4.0 base on this chart. I can get you access to my 2018 instance. But I spin it up and down as part of my pipeline... Let me think on how best to get you one. Or you can install in a VM locally.

[SebastianSchuetze]

I am already invited to the Microsoft tenant since I worked with Vesa (PM on SP / PnP Dev Experience) and some other small projects with others. So one possibility would be to give me startup permission with the role DevTest Labs User on the VM with this I would see the VM (not everything), can start and stop it. And I can RDP to it if I have credentials.

Yes TFS 2018 is 4.0, but this module officially supports TFS 2017 still. And 2017 U2 has 3.2. And the default values should not be higher than 3.2 I guess. Unless we drop TFS 2017 support.

[DarqueWarrior]

In the original comment you mentioned 2018

Adjusting default API version for the Build API in TFS 2018 as ...

So I was not sure which version you were targeting. But you are saying the default minimum version that should work everywhere?

[DarqueWarrior]

hmmm given that chart maybe Set-VSTeamAPIVersion should have a value that matches each release? Currently we have TFS2017, TFS2018, AzD2019, VSTS, AzD. Maybe we should have TFS2017RTW, TFS2017U1, TFS2017U2, TFS2018RTW etc.. Thoughts?

[SebastianSchuetze]

If I think a bit about it, then I think the default minimum Version should either match the newest API version (which is always Azure DevOps Services) or the minimum supported version by us. I would favour always the newest API version by default and somehow give a warning if no specific version has been set manually. So people know that they maybe should do it.

Then I agree we can also add a value for each update. That I think makes it the easiest way together with a warning.

[DarqueWarrior]

OK I will work on this one next.

[DarqueWarrior]

I just created a collection of local VMs with TFS2017, TFS2018 and AZD2019. The integration tests fail against AZD2019 because not all the 5.0 APIs are released. Some are still in preview. For example distributedtask is not 5.0 it is 5.0-preview. You can review this by running Get-VSTeamOption against your TFS or AZD.

id              : 900fa995-c559-4923-aae7-f8424fe4fbea
area            : distributedtask
resourceName    : queues
routeTemplate   : {project}/_apis/{area}/{resource}/{queueId}
resourceVersion : 1
minVersion      : 2.0
maxVersion      : 5.0
releasedVersion : 0.0

The releasedVersion is 0.0 meaning it has never been released. Version 5.0 is the max version but is in preview, otherwise, the releasedVersion would also equal 5.0.

I will be playing with this this week in between Build. This will allow me to find what the actual values for all the areas should be. The chart is docs is good but does not tell the whole story.

[SebastianSchuetze]

@DarqueWarrior Would you be able to use this PR for adding the changes?

[DarqueWarrior]

I will be adding these in the Versions PR.