Use Alpha and Beta for our prerelease tags instead of dev and preview for all languages

[weshaggard]

preview in the name of packages can potentially cause confusion
because some preview azure service features generally have to
charge less then full price for the service. Since the SDK versions
aren't exactly tied to preview or GA versions of the service we want
to avoid this confusion and just use the word beta for our pre-GA
package versioning.

[weshaggard]

@ramya-rao-a @bterlson @xirzec could I get someone from JS team to review and approve this?

[xirzec]

I think the only outstanding issue is the fact that a dependency set to "^1.0.0-beta.1" will automatically roll forward to "1.0.0-dev.20200720.1" since it is semantically higher and compatible, which would be unexpected since dailies are generally not stable or well supported.

Internally we avoid this by pinning preview versions, but unless a user invokes npm with --save-exact, they will not get that behavior and might end up installing a daily instead of a preview release.

Are you comfortable renaming dev to alpha in order to mitigate?

[weshaggard]

Are you comfortable renaming dev to alpha in order to mitigate?

I would like to avoid renaming dev to alpha, dev has a particular meaning that indicates it is a daily dev build and I'd like that to also remain consistent with the other languages.

I will say that the problem you call out is an problem with the other languages as well but it is slightly mitigated there because the other languages require you to add an additional feed source in order to get dev builds. npm doesn't allow us to easily segregate and have packages from multiple feeds for the same scope so we had to publish the dev packages to npm directly under the dev tag.

How much of an issue do you think it will be for folks that depend on "^1.0.0-beta.1" to roll-forward to the latest dev version? Aren't they already sort of signing up for any prerelease by using "^" on a prerelease, by its nature that is already accepting risk because we don't guarantee compat between prereleases. I understand our dev builds might be a little more volatile but I'm not sure if that is a big enough concern to not make this change. If customers do hit issues they can always pin to a beta version like we do.

[xirzec]

How much of an issue do you think it will be for folks that depend on "^1.0.0-beta.1" to roll-forward to the latest dev version? Aren't they already sort of signing up for any prerelease by using "^" on a prerelease, by its nature that is already accepting risk because we don't guarantee compat between prereleases. I understand our dev builds might be a little more volatile but I'm not sure if that is a big enough concern to not make this change. If customers do hit issues they can always pin to a beta version like we do.

I'm not sure I am swayed by your argument. The idea of semver is to have semantically meaningful versions. We're abusing semver in this case to provide nightlies, because as you mention it's a pain to release nightlies otherwise and npm has no support for release channels.

While you are correct that we allow breaking changes between prereleases, we at least document these changes and provide upgrade advice in the changelog. This is not necessarily true for every nightly snapshot of master as sometimes the release notes are in flux until we ship a prerelease. Also prereleases (generally) occur at a frequency of once a month, rather than every day.

I'm not sure I fully understand the motivation for this change in the first place. Why would the version string used by an SDK package have anything to do with the billing status of an Azure service? We have never aligned to the version strings of APIs themselves.

Also, many consumer products have coopted the use of beta to mean pre-release and not fully functional. If a user might expect some discount for using "preview" software, why would they not demand the same of a beta?

[xirzec]

One last thought - you use the term prerelease - a nice word that starts with a 'p'. Why don't we use that instead of beta or preview if the only trouble is the English word "preview"?

[weshaggard]

Thanks for the feedback @xirzec. I know for at least python and java "beta" has special meaning in their versions as they don't fully support semver, which is why they were already not using "preview". Given that we were already using beta for those languages we chose to try and align on beta for the other 2 languages given the feedback about the extra meaning of "preview" from a service point of view.

@kurtzeborn @Petermarcu what are your guys thoughts on moving from "preview" to "prerelease"? It would avoid the issue that the storage team pointed out and not have the potential roll forward issue @xirzec points out for JS.

@AlexGhiondea would .NET have any issue with using "prerelease" instead of "beta" or "preview"?

[kurtzeborn]

Looks like "beta" may be a problem for JS. I'm fine with the word "prerelease" instead of "preview" for .NET and JS then. I'll ping @amishra-dev and @pemari-msft and see if they have concerns.

[kurtzeborn]

We talked about this in the storage sync today and using the word "prerelease" for JS is fine with the storage team. Their preference is to use "beta" for .NET since that matches Java (and Python somewhat). They also think that using the word "beta" for other langauges (C/C++, Go, mobile) makes the most sense since it would match the rest (unless there are idiomatic reasons not to).

[weshaggard]

Based on various feedback we decided to move all languages to beta except JS and keep them with preview as they are due to the dev versioning conflict called out by @xirzec.

[weshaggard]

OK after may conversations on this top I've updated the guidelines based on the following:

To summarize the changes:
For preview releases we will use “-beta” as the prerelease tag for all languages. Instead of “-preview”.
For daily dev builds we will use “-alpha” as the prerelease tag for all languages. Instead of “-dev”.

The move from “preview” to “beta” is to make the languages consistent and is to avoid confusion with using “preview” as it has meaning for Azure services that indicates people get discounted rates. The move from “dev” to “alpha” is to have the versions that sort older then “beta” and helps ensure that our daily dev versions, which are less stable, don’t end up as the “latest” version for our customers when they are testing out our previews. Folks will have to take an extra opt-in step if they wish to test our daily dev versions, it won’t happen by accident like it can today.

I've also added a note in each language section on how folks can remain on the daily dev version train if they want to opt-in to those versions.

Can I please get the language leads and/or architects to review and sign-off on this PR documenting the changes?

• .NET @AlexGhiondea @KrzysztofCwalina
• Java @joshfree @JonathanGiles
• JS/TS @ramya-rao-a @bterlson
• Python @lmazuel @johanste

[weshaggard]

FYI @Azure/azure-sdk-eng

[weshaggard]

Thanks for all the feedback. I'm going to override the CI failure and merge as the broken link is unrelated to these changes and I've fixed in another PR.