-
Notifications
You must be signed in to change notification settings - Fork 396
Collaborators: Release New Nuget
Collaborators are able to release new nugets by pushing new versions of project files directly to the master
branch, although the same could be achieved by pull requests from anyone. Usually we release a new version of nugets for every merged pull request, or for a batch of PRs if several were merged in.
This section assumes you want to push a new set of nugets for the code that currently exists in master
branch of angularsen/UnitsNet
repo. You only need to bump the JSON serialization version if that code was touched or if a breaking change was introduced in the UnitsNet
nuget.
The build server will build and attempt to push nugets for every git push to the master
branch. It will only succeed to push new nugets if the version changed since nuget.org does not accept publishing the same version twice.
Set up your local master
branch to use angularsen/UnitsNet
repo as upstream, and use your fork myuser/UnitsNet
as upstream for all feature branches. See guide on setting this up.
- Checkout
master
and pull in latest changes:git pull --rebase
- Bump version of
UnitsNet
,UnitsNet.Signed
andUnitsNet.WindowsRuntime
nugets (creates commit and tag)- /Build/bump-version-UnitsNet-major.bat for breaking changes
- /Build/bump-version-UnitsNet-minor.bat for new things
- /Build/bump-version-UnitsNet-patch.bat for bug fixes
- If JSON changed, bump version of
UnitsNet.Serialization.Json
andUnitsNet.Serialization.Json.Signed
nugets - Push changes and tag(s):
git push --follow-tags
- Create release by editing tag in GitHub, copy in all notable commit messages since previous tag (usually pull request commits)
- View build progress and details at https://ci.appveyor.com/project/angularsen/unitsnet
git checkout master # Checkout master
git pull --rebase # Pull latest origin/master, rebase any local commits on top
./Build/bump-version-UnitsNet-minor.bat # Increase the version and create an annotated git tag
git push --follow-tags # Push code and tag
The goal of this guide is to have a consistent setup of git remotes:
-
origin
:angularsen/UnitsNet
, for master branch -
my
:myuser/UnitsNet
, for pull request branches
Then point master
to official repo.
# rename the fork remote to 'my'
git remote rename origin my
# Add official repo as origin remote using either SSH or HTTPS url
git remote add origin git@github.com:angularsen/UnitsNet.git
git remote add origin https://github.com/angularsen/UnitsNet.git
# Checkout master and point it to origin/master
git checkout master
git branch --set-upstream-to=origin/master
Then master
branch is already pointing to official repo and you just need to add your fork as a remote to push feature branches there.
# Add your fork repo as 'my' remote using either SSH or HTTPS url
git remote add my git@github.com:myuser/UnitsNet.git
git remote add my https://github.com/myuser/UnitsNet.git
Use your fork when creating and pushing new branches. This is to avoid a clutter of work-in-progress branches before they are ready for review.
git checkout -b new-branch origin/master # new branch, based on remote master
# Add some commits...
git push my new-branch # push branch to your fork
# Create PR from your fork's github web page
This should normally never be necessary, but if for any reason you need to deploy new nugets outside AppVeyor build server then you can do it like this.
The general flow is documented at nuget.org: https://docs.microsoft.com/en-us/nuget/create-packages/publish-a-package
- Obtain nuget API key with access to push
UnitsNet
and related nuget packages - Set nuget API key on your PC:
nuget setApiKey Your-API-Key
- Run
build.bat
to build everything - Run
/Build/push-nugets.bat
to push nugets - Alternatively run
dotnet nuget push <nuget path>
for nugets in/Artifacts/NuGet
folder