Add release documentation #1995
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
SonnyBA
requested review from
alextreme,
sergei-maertens,
stevenbal,
michielverhoef and
MatthijsBekendam
SonnyBA
force-pushed
the
add-release-documentation
branch
from
04ea199 to
f768c7a
Compare
stevenbal
reviewed
May 2, 2022
Comment on lines
31
to
35
| Ook bugfixes en nieuw features zijn idealiter gericht naar de `master` branch tenzij | ||
| het gaat om een bugfix of feature voor een specifieke release. Er kan daarnaast | ||
| gekozen worden om de bugfix niet alleen naar `master` toe te richten maar ook te backporten | ||
| naar specifiek releases. Wanneer het gaat om zogenaamde "breaking changes" dien je | ||
| altijd een nieuwe release te doen en hiermee ook de major versie op te hogen (e.g van `1.1.1` naar `2.0.0`). |
There was a problem hiding this comment.
Kleine suggesties, ziet er goed uit verder 👍
Suggested change
| Ook bugfixes en nieuw features zijn idealiter gericht naar de `master` branch tenzij | |
| het gaat om een bugfix of feature voor een specifieke release. Er kan daarnaast | |
| gekozen worden om de bugfix niet alleen naar `master` toe te richten maar ook te backporten | |
| naar specifiek releases. Wanneer het gaat om zogenaamde "breaking changes" dien je | |
| altijd een nieuwe release te doen en hiermee ook de major versie op te hogen (e.g van `1.1.1` naar `2.0.0`). | |
| Ook bugfixes en nieuw features zijn idealiter gericht naar de `master` branch, tenzij | |
| het gaat om een bugfix of feature voor een specifieke release. Er kan daarnaast | |
| gekozen worden om de bugfix niet alleen naar `master` toe te richten maar ook te backporten | |
| naar specifieke releases. Wanneer het gaat om zogeheten "breaking changes" dien je | |
| altijd een nieuwe release te doen en hiermee ook de major versie op te hogen (e.g van `1.1.1` naar `2.0.0`). |
sergei-maertens
suggested changes
May 3, 2022
Comment on lines
7
to
9
| Het ontwikkelen van de ZGW componenten gebeurd aan de hand van het git branching | ||
| model "[OneFlow]". In deze tutorial wordt beschreven hoe een je om dient te gaan | ||
| met dit type branch model. |
There was a problem hiding this comment.
Suggested change
| Het ontwikkelen van de ZGW componenten gebeurd aan de hand van het git branching | |
| model "[OneFlow]". In deze tutorial wordt beschreven hoe een je om dient te gaan | |
| met dit type branch model. | |
| Het ontwikkelen van de ZGW componenten gebeurt aan de hand van het `git`-branching | |
| model "[OneFlow]". Dit document beschrijft hoe je om dient te gaan met dit type branch model. |
Comment on lines
11
to
13
| ## Standaard branch | ||
| Voor het aanmaken van nieuwe features of bugfixes dien je gebruik te maken van de | ||
| `master` branch tenzij je een feature of bugfix wilt toevoegen voor een specifieke versie. |
There was a problem hiding this comment.
Suggested change
| ## Standaard branch | |
| Voor het aanmaken van nieuwe features of bugfixes dien je gebruik te maken van de | |
| `master` branch tenzij je een feature of bugfix wilt toevoegen voor een specifieke versie. | |
| ## Standaardbranch | |
| Voor het aanmaken van nieuwe features of bugfixes dien je gebruik te maken van de | |
| `master` branch tenzij je een feature of bugfix wilt toevoegen voor een specifieke versie. | |
| Bijvoorbeeld `git checkout -b feature/some-feature master` of `git checkout -b issue/some-bugfix stable/1.2.x`. |
Comment on lines
11
to
13
| ## Standaard branch | ||
| Voor het aanmaken van nieuwe features of bugfixes dien je gebruik te maken van de | ||
| `master` branch tenzij je een feature of bugfix wilt toevoegen voor een specifieke versie. |
There was a problem hiding this comment.
Suggested change
| ## Standaard branch | |
| Voor het aanmaken van nieuwe features of bugfixes dien je gebruik te maken van de | |
| `master` branch tenzij je een feature of bugfix wilt toevoegen voor een specifieke versie. | |
| ## Standaardbranch | |
| Voor het aanmaken van nieuwe features of bugfixes dien je gebruik te maken van de | |
| `master` branch tenzij je een feature of bugfix wilt toevoegen voor een specifieke versie. | |
| Bijvoorbeeld `git checkout -b feature/some-feature master` of `git checkout -b issue/some-bugfix stable/1.2.x`. |
Comment on lines
16
to
18
| Voor testomgevingen wordt gebruikt gemaakt van de `master` branch. Om een nieuwe versie | ||
| te deployen kan je als ontwikkelaar een [git tag] gebruiken of gebruik maken van de sha-256 checksum | ||
| van een specifieke commit. Bij het gebruik van een git tag dien je het volgende format te hanteren: |
There was a problem hiding this comment.
Suggested change
| Voor testomgevingen wordt gebruikt gemaakt van de `master` branch. Om een nieuwe versie | |
| te deployen kan je als ontwikkelaar een [git tag] gebruiken of gebruik maken van de sha-256 checksum | |
| van een specifieke commit. Bij het gebruik van een git tag dien je het volgende format te hanteren: | |
| Voor testomgevingen wordt gebruikt gemaakt van de `master` branch. Om een nieuwe versie | |
| te deployen kan je als ontwikkelaar een [git tag] gebruiken of gebruik maken van de sha-256 checksum | |
| van een specifieke container image. Bij het gebruik van een git tag dien je het volgende format te hanteren: |
Comment on lines
16
to
18
| Voor testomgevingen wordt gebruikt gemaakt van de `master` branch. Om een nieuwe versie | ||
| te deployen kan je als ontwikkelaar een [git tag] gebruiken of gebruik maken van de sha-256 checksum | ||
| van een specifieke commit. Bij het gebruik van een git tag dien je het volgende format te hanteren: |
There was a problem hiding this comment.
Suggested change
| Voor testomgevingen wordt gebruikt gemaakt van de `master` branch. Om een nieuwe versie | |
| te deployen kan je als ontwikkelaar een [git tag] gebruiken of gebruik maken van de sha-256 checksum | |
| van een specifieke commit. Bij het gebruik van een git tag dien je het volgende format te hanteren: | |
| Voor testomgevingen wordt gebruikt gemaakt van de `master` branch. Om een nieuwe versie | |
| te deployen kan je als ontwikkelaar een [git tag] gebruiken of gebruik maken van de sha-256 checksum | |
| van een specifieke container image. Bij het gebruik van een git tag dien je het volgende format te hanteren: |
|
|
||
| ## Productieomgevingen | ||
| Productieomgevingen worden alleen gebruikt in combinatie met daadwerkelijke release versies. | ||
| Voor deze versies is altijd een branch aangemaakt met het volgende format: `<major>.<minor>.x`. |
There was a problem hiding this comment.
Suggested change
| Voor deze versies is altijd een branch aangemaakt met het volgende format: `<major>.<minor>.x`. | |
| Voor deze versies is altijd een branch aangemaakt met het volgende format: `stable/<major>.<minor>.x`. |
|
|
||
| ## Productieomgevingen | ||
| Productieomgevingen worden alleen gebruikt in combinatie met daadwerkelijke release versies. | ||
| Voor deze versies is altijd een branch aangemaakt met het volgende format: `<major>.<minor>.x`. |
There was a problem hiding this comment.
Suggested change
| Voor deze versies is altijd een branch aangemaakt met het volgende format: `<major>.<minor>.x`. | |
| Voor deze versies is altijd een branch aangemaakt met het volgende format: `stable/<major>.<minor>.x`. |
Comment on lines
26
to
28
| Een voorbeeld hiervan zou kunnen zijn: `1.2.x`. Alleen bugfixes kunnen nog toegevoegd worden | ||
| aan deze branches. Een nieuwe minor of major versie betekent een nieuwe release en | ||
| daarbij een nieuwe branch (bijvoorbeeld in het geval van een nieuwe minor release `1.3.x`). |
There was a problem hiding this comment.
Suggested change
| Een voorbeeld hiervan zou kunnen zijn: `1.2.x`. Alleen bugfixes kunnen nog toegevoegd worden | |
| aan deze branches. Een nieuwe minor of major versie betekent een nieuwe release en | |
| daarbij een nieuwe branch (bijvoorbeeld in het geval van een nieuwe minor release `1.3.x`). | |
| Een voorbeeld hiervan zou kunnen zijn: `stable/1.2.x`. Alleen bugfixes kunnen nog toegevoegd worden | |
| aan deze branches. Een nieuwe minor of major versie betekent een nieuwe release en | |
| daarbij een nieuwe branch (bijvoorbeeld in het geval van een nieuwe minor release `stable/1.3.x`). |
Comment on lines
26
to
28
| Een voorbeeld hiervan zou kunnen zijn: `1.2.x`. Alleen bugfixes kunnen nog toegevoegd worden | ||
| aan deze branches. Een nieuwe minor of major versie betekent een nieuwe release en | ||
| daarbij een nieuwe branch (bijvoorbeeld in het geval van een nieuwe minor release `1.3.x`). |
There was a problem hiding this comment.
Suggested change
| Een voorbeeld hiervan zou kunnen zijn: `1.2.x`. Alleen bugfixes kunnen nog toegevoegd worden | |
| aan deze branches. Een nieuwe minor of major versie betekent een nieuwe release en | |
| daarbij een nieuwe branch (bijvoorbeeld in het geval van een nieuwe minor release `1.3.x`). | |
| Een voorbeeld hiervan zou kunnen zijn: `stable/1.2.x`. Alleen bugfixes kunnen nog toegevoegd worden | |
| aan deze branches. Een nieuwe minor of major versie betekent een nieuwe release en | |
| daarbij een nieuwe branch (bijvoorbeeld in het geval van een nieuwe minor release `stable/1.3.x`). |
sergei-maertens
approved these changes
May 9, 2022
Comment on lines
7
to
9
| Het ontwikkelen van de ZGW componenten gebeurd aan de hand van het git branching | ||
| model "[OneFlow]". In deze tutorial wordt beschreven hoe een je om dient te gaan | ||
| met dit type branch model. |
There was a problem hiding this comment.
Suggested change
| Het ontwikkelen van de ZGW componenten gebeurd aan de hand van het git branching | |
| model "[OneFlow]". In deze tutorial wordt beschreven hoe een je om dient te gaan | |
| met dit type branch model. | |
| Het ontwikkelen van de ZGW componenten gebeurt aan de hand van het `git`-branching | |
| model "[OneFlow]". Dit document beschrijft hoe je om dient te gaan met dit type branch model. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Om het voor ontwikkelaars van de ZGW componenten inzichtelijk te maken hoe er verwacht wordt dat er om wordt gegaan met branches en verschillende versies heb ik een beknopt stukje documentatie toegevoegd. Dit vooral om te voorkomen dat er een wirwar gaat ontstaan van release branches die dat eigenlijk niet zijn en consistent te zijn in de benaming van tags en branches.