aspnet
/
Identity
зеркало из https://github.com/aspnet/Identity.git
1
0
Форкнуть 0
Код Задачи Пакеты Проекты Релизы Вики Активность
Identity/version.props

18 строки
1.8 KiB
Plaintext
Исходник Постоянная ссылка Обычный вид История

Revert "Bumping version from 2.2.0 to 3.0.0" This reverts commit b005ef7831eb511ad5ad960546f2077f1fac7f9a.
2018-08-18 02:09:31 +03:00
<Project>
Pin tool and package versions to make builds more repeatable
2017-11-01 00:43:19 +03:00
<PropertyGroup>
Bumping version from 2.2.0 to 3.0.0
2018-06-29 02:48:52 +03:00
<VersionPrefix>3.0.0</VersionPrefix>
<VersionSuffix>alpha1</VersionSuffix>
Update branding to 2.1.6-servicing (#1994) Per discussion with our team, we want to make the following changes to versioning during servicing updates: * The versioning on packages with ship with ASP.NET Core should be consistent * (No change) on packages with changes in them ship during servicing updates * Version gaps are okay. For example, this repo is producing a patch for 2.1.6, so packages will be 2.1.6. It did not patch for 2.1.4 or 2.1.3 so those versions will be skipped. This also includes another minor change: for consistency with the rest of the .NET Core teams, pre-release servicing builds will be 2.1.x-servicing-buildnumber.
2018-10-05 22:09:40 +03:00
<PackageVersion Condition="'$(IsFinalBuild)' == 'true' AND ('$(VersionSuffix)' == 'servicing' OR '$(VersionSuffix)' == 'rtm') ">$(VersionPrefix)</PackageVersion>
<PackageVersion Condition="'$(IsFinalBuild)' == 'true' AND '$(VersionSuffix)' != 'servicing' AND '$(VersionSuffix)' != 'rtm' ">$(VersionPrefix)-$(VersionSuffix)-final</PackageVersion>
Pin tool and package versions to make builds more repeatable
2017-11-01 00:43:19 +03:00
<BuildNumber Condition="'$(BuildNumber)' == ''">t000</BuildNumber>
Prepend FeatureBranchVersionPrefix if FeatureBranchVersionSuffix is specified
2018-03-06 21:04:14 +03:00
<FeatureBranchVersionPrefix Condition="'$(FeatureBranchVersionPrefix)' == ''">a-</FeatureBranchVersionPrefix>
<VersionSuffix Condition="'$(VersionSuffix)' != '' And '$(FeatureBranchVersionSuffix)' != ''">$(FeatureBranchVersionPrefix)$(VersionSuffix)-$([System.Text.RegularExpressions.Regex]::Replace('$(FeatureBranchVersionSuffix)', '[^\w-]', '-'))</VersionSuffix>
Pin tool and package versions to make builds more repeatable
2017-11-01 00:43:19 +03:00
<VersionSuffix Condition="'$(VersionSuffix)' != '' And '$(BuildNumber)' != ''">$(VersionSuffix)-$(BuildNumber)</VersionSuffix>
Bumping version from 2.2.0 to 3.0.0
2018-06-29 02:48:52 +03:00
<ExperimentalVersionPrefix>0.6.0</ExperimentalVersionPrefix>
<ExperimentalVersionSuffix>alpha1</ExperimentalVersionSuffix>
Update branding to 2.1.6-servicing (#1994) Per discussion with our team, we want to make the following changes to versioning during servicing updates: * The versioning on packages with ship with ASP.NET Core should be consistent * (No change) on packages with changes in them ship during servicing updates * Version gaps are okay. For example, this repo is producing a patch for 2.1.6, so packages will be 2.1.6. It did not patch for 2.1.4 or 2.1.3 so those versions will be skipped. This also includes another minor change: for consistency with the rest of the .NET Core teams, pre-release servicing builds will be 2.1.x-servicing-buildnumber.
2018-10-05 22:09:40 +03:00
<ExperimentalPackageVersion Condition="'$(IsFinalBuild)' == 'true' AND ('$(ExperimentalVersionSuffix)' == 'servicing' OR '$(ExperimentalVersionSuffix)' == 'rtm') ">$(ExperimentalVersionPrefix)</ExperimentalPackageVersion>
<ExperimentalPackageVersion Condition="'$(IsFinalBuild)' == 'true' AND '$(ExperimentalVersionSuffix)' != 'servicing' AND '$(ExperimentalVersionSuffix)' != 'rtm' ">$(ExperimentalVersionPrefix)-$(ExperimentalVersionSuffix)-final</ExperimentalPackageVersion>
Duplicate logic for Experimental
2018-02-17 01:09:58 +03:00
<ExperimentalVersionSuffix Condition="'$(ExperimentalVersionSuffix)' != '' And '$(BuildNumber)' != ''">$(ExperimentalVersionSuffix)-$(BuildNumber)</ExperimentalVersionSuffix>
Pin tool and package versions to make builds more repeatable
2017-11-01 00:43:19 +03:00
</PropertyGroup>
</Project>