Azure/azure-functions-tooling-feed

Releases shouldn't be versions

Closed this issue · 3 comments

These refs should be GUIDs not valid versions

},
"v2": {
"release": "2.8.0",

It's very confusing to have them as versions because VS uses that for folder names and then people start reporting that as the version.

I have seen this from time to time, I believe there was a discussion on whether to use GUIDs or version semantic versions.
@paulbatum Do you remember why we had decided to use versions over GUIDs?

There are a couple of changes in the pipeline that should mitigate this issue. As of now there are 2 places where version is visible to users.

  1. Downloading prompt, when we release a new CLI.
  • VS is going to make the download prompt generic, without version numbers. Like downloading new version of the CLI.
  1. The window title of of the cli console when you press F5 from VS.
  • We are going to use the no-runtime version of CLI, with the new VSIX. This would remove the version number and path from console title bar and just have dotnet.exe there.

Yeah I remember discussing this and seriously considering GUIDs at one point. One reason I preferred the current approach is that its easier to make sense of the file system layout in %localappdata%\AzureFunctionsTools\Releases. Similarly, you can do things like infer what the "second last release" was. I have a feeling there was something else that I can't recall right now..

My preference would be to stay with the current scheme. But I agree with you that places where the version number appears as part of the normal F5 experience are problematic.

The version has been removed from downloading prompt in VS, #11. It is only present in the window title of of the cli console when you press F5 from VS.