Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change prerelease versioning #14780

Merged
merged 2 commits into from
Sep 2, 2020
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
13 changes: 6 additions & 7 deletions doc/dev/Versioning.md
Original file line number Diff line number Diff line change
Expand Up @@ -9,25 +9,25 @@ Package version will look like:
MAJOR.MINOR.PATCH-PRERELEASE
```

In the project file use the `Version` property to define the `MAJOR.MINOR.PATCH-preview.X` part of the version.
In the project file use the `Version` property to define the `MAJOR.MINOR.PATCH-beta.X` part of the version.

```
<Version>1.0.0-preview.1</Version>
<Version>1.0.0-beta.1</Version>
```

By default builds will replace any prerelease identifier with a `dev.yyyyMMdd.r` to ensure we have unique package versions. The date will come from either
By default builds will replace any prerelease identifier with a `alpha.yyyyMMdd.r` to ensure we have unique package versions for dev builds. The date will come from either
today's date or a property named `OfficialBuildId` which we will pass as part of our build pipelines.

If we need to produce a package that is not a dev version and has the version in the project (i.e. stable or preview) then the `SkipDevBuildNumber` should
If we need to produce a package that is not a dev package with an alpha version and has the version in the project (i.e. stable or beta) then the `SkipDevBuildNumber` should
be passed as `true` to the packaging command.

## Incrementing the version

See [Incrementing after release](https://github.com/Azure/azure-sdk/blob/master/docs/policies/releases.md#incrementing-after-release) for general guidance but at a
high level we will do the following versioning changes:

- After a preview release we bump the number after the preview. `1.0.0-preview.1` -> `1.0.0-preview.2`
- After a GA release we bump the minor version and switch to preview 1. `1.0.0` -> `1.1.0-preview.1`
- After a beta release we bump the number after the beta. `1.0.0-beta.1` -> `1.0.0-beta.2`
- After a GA release we bump the minor version and switch to beta 1. `1.0.0` -> `1.1.0-beta.1`
- Prior to a hot-fix release we bump the patch version. `1.0.0` -> `1.0.1`

Versions are automatically bumped up in package project `.csproj` files as well as package changelog `CHANGELOG.md` as part of the release process. To increment a version locally make use of the `eng\scripts\Update-PkgVersion.ps1` script.
Expand Down Expand Up @@ -61,4 +61,3 @@ The versioning scheme imposes the following limits on these version parts:
| Parameter | Description |
| -------------------------- | ------------------------------------------------------------ |
| OfficialBuildId | ID of current build. The accepted format is `yyyyMMdd.r`. Should be passed to build in YAML official build defintion. |

4 changes: 2 additions & 2 deletions eng/Versioning.targets
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@
<_BuildNumber>$(OfficialBuildId)</_BuildNumber>
<_BuildNumber Condition="'$(OfficialBuildId)' == ''">$([System.DateTime]::Now.ToString(yyyyMMdd)).1</_BuildNumber>
<HasReleaseVersion>true</HasReleaseVersion>
<HasReleaseVersion Condition="$(Version.Contains('preview'))">false</HasReleaseVersion>
<HasReleaseVersion Condition="$(Version.Contains('preview')) or $(Version.Contains('beta'))">false</HasReleaseVersion>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this check for alpha as well?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No as that should never be committed into the project file.

<_VersionInProject>$(Version)</_VersionInProject>
</PropertyGroup>

Expand All @@ -13,7 +13,7 @@
<_PrereleaseIndex>$(Version.IndexOf('-'))</_PrereleaseIndex>
<Version Condition="$(_PrereleaseIndex) &gt; 0">$(Version.SubString(0, $(_PrereleaseIndex)))</Version>

<Version>$(Version)-dev.$(_BuildNumber)</Version>
<Version>$(Version)-alpha.$(_BuildNumber)</Version>
</PropertyGroup>

<!--
Expand Down
3 changes: 3 additions & 0 deletions sdk/template/Azure.Template/CHANGELOG.md
Original file line number Diff line number Diff line change
@@ -1,5 +1,8 @@
# Release History

## 1.0.3-beta.1 (2020-08-27)
- Test new alpha beta versioning

## 1.0.2-preview.15 (2020-06-29)
- Test release pipeline

Expand Down
2 changes: 1 addition & 1 deletion sdk/template/Azure.Template/src/Azure.Template.csproj
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@
<PropertyGroup>
<Description>This is a template project to demonstrate how to create a package that uses code generation as well as use for testing our build and release pipelines</Description>
<AssemblyTitle>Azure SDK Template</AssemblyTitle>
<Version>1.0.2-preview.15</Version>
<Version>1.0.3-beta.1</Version>
<PackageTags>Azure Template</PackageTags>
<TargetFrameworks>$(RequiredTargetFrameworks)</TargetFrameworks>
</PropertyGroup>
Expand Down