Skip to content

Commit ede71c4

Browse files
committed
updated release process
1 parent ab3533b commit ede71c4

File tree

1 file changed

+6
-4
lines changed

1 file changed

+6
-4
lines changed

docs/building/releaseprocess.rst

Lines changed: 6 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
11
Release process
22
===============
33

4-
* The release process works best with GitHubFlow branching.
4+
* The release process works best with Git Flow branching.
55
* Contributors can do whatever they want on PRs and merges to master will result in packages being released to GitHub and NuGet.
66

77
Ocelot uses the following process to accept work into the NuGet packages.
@@ -10,7 +10,7 @@ Ocelot uses the following process to accept work into the NuGet packages.
1010

1111
2. User creates a fork and branches from this (unless a member of core team, they can just create a branch on the main repo) e.g. feat/xxx, fix/xxx etc. It doesn't really matter what the xxx is. It might make sense to use the issue number and maybe a short description. I don't care as long as it has (feat, fix, refactor)/xxx :)
1212

13-
3. When the user is happy with their work they can create a pull request against master in GitHub with their changes. The user must follow the `SemVer <https://semver.org/>`_ support for this is provided by `GitVersion <https://gitversion.readthedocs.io/en/latest/>`_. So if you need to make breaking changes please make sure you use the correct commit message so GitVersion uses the correct semver tags. Do not manually tag the Ocelot repo this will break things.
13+
3. When the user is happy with their work they can create a pull request against develop in GitHub with their changes. The user must follow the `SemVer <https://semver.org/>`_ support for this is provided by `GitVersion <https://gitversion.readthedocs.io/en/latest/>`_. So if you need to make breaking changes please make sure you use the correct commit message so GitVersion uses the correct semver tags. Do not manually tag the Ocelot repo this will break things.
1414

1515
4. The Ocelot team will review the PR and if all is good merge it, else they will suggest feedback that the user will need to act on. In order to speed up getting a PR the user should think about the following.
1616
- Have I covered all my changes with tests at unit and acceptance level?
@@ -23,9 +23,11 @@ In order for a PR to be merged the following must have occured.
2323
- Build must not have slowed down dramatically.
2424
- The main Ocelot package must not have taken on any non MS dependencies.
2525

26-
5. After the PR is merged to master the release process will begin which builds the code, versions it, pushes artifacts to GitHub and NuGet packages to NuGet.
26+
5. After the PR is merged to develop the Ocelot NuGet packages will not be updated until a release is created.
2727

28-
6. The final step is to go back to GitHub and close any issues that are now fixed. You should see something like this in`GitHub <https://github.com/ThreeMammals/Ocelot/releases/tag/13.0.0>`_ and this in `NuGet <https://www.nuget.org/packages/Ocelot/13.0.0>`_.
28+
6. When enough work has been completed to justify a new release develop will be merged into master the release process will begin which builds the code, versions it, pushes artifacts to GitHub and NuGet packages to NuGet.
29+
30+
7. The final step is to go back to GitHub and close any issues that are now fixed. You should see something like this in`GitHub <https://github.com/ThreeMammals/Ocelot/releases/tag/13.0.0>`_ and this in `NuGet <https://www.nuget.org/packages/Ocelot/13.0.0>`_.
2931

3032
Notes
3133
-----

0 commit comments

Comments
 (0)