From d93b97b28fee20409933e74e6d44a569dbd18a77 Mon Sep 17 00:00:00 2001 From: Meinte Boersma Date: Thu, 18 Nov 2021 13:37:29 +0100 Subject: [PATCH 1/7] Initiate branch for release 2.4.0. --- CHANGELOG.md | 3 +++ README.md | 2 +- 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 31e3e06..c8c923d 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1,5 +1,8 @@ # Change log +## Release 2.4.0 + + ## Release 2.3.0 Changes: diff --git a/README.md b/README.md index aa688f1..142a35f 100644 --- a/README.md +++ b/README.md @@ -2,7 +2,7 @@ This repository contains the value sets referenced by the EU Digital COVID Certificate (DCC) [JSON Schema](https://github.com/ehn-dcc-development/ehn-dcc-schema). -Release: 2.3.0 +Release: 2.4.0 Note that these value sets do not form a core part of the [JSON Schema](https://github.com/ehn-dcc-development/ehn-dcc-schema) but are referenced by it. These value sets can (and should) be regularly updated and distributed from the main Digital COVID Certificate Gateway (DCCG), under clear versioning and release management. From a78e94a44045b521c394125a0f87c5876a6f2974 Mon Sep 17 00:00:00 2001 From: Meinte Boersma Date: Tue, 16 Nov 2021 23:37:15 +0100 Subject: [PATCH 2/7] Describe new versioning process. --- VERSIONING.md | 38 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 38 insertions(+) create mode 100644 VERSIONING.md diff --git a/VERSIONING.md b/VERSIONING.md new file mode 100644 index 0000000..bb2f5c7 --- /dev/null +++ b/VERSIONING.md @@ -0,0 +1,38 @@ +# Versioning + +This file documents the versioning process. + +Versioning of this Git repository is organised as a simplified [Git flow](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow) (or [see here](https://medium.com/@patrickporto/4-branching-workflows-for-git-30d0aaee7bf)). +The `main` branch is the _only_ primary branch, and therefore also serves as the _default branch_ for GitHub. +The version history is organised around **releases**. +Each release is identified through a [semver version number](https://semver.org/). + + +## Releasing + +Releases are prepared in branches named `release/`. +After preparation has finished, a _Pull Request_ (PR) from the release branch into `main` is created. +This PR serves as the trigger a code review for that release, possibly leading to further work being done in that release branch. + +After enough reviewers have approved the PR, it can be merged into `main`. +Merging the PR is done through “rebase + merge commit”, _without_ fast-forwarding. +That keeps the history very clean, and tidy - linear, with the incremental work done for each release clearly identifiable. +After merging the PR for a release into `main`, the merge commit is tagged as ``. + +It's advisable to rebase a release branch manually, as there's no guarantee that a conflict-free automatic rebase is syntactically, or semantically correct. +After a manual rebase, the rebased branch has to be force-pushed. + +The release branch can be deleted after merging the PR, for the following reasons: + +- A branch is essentially a label on a HEAD commit, and a tag fulfills the labelling function just as well. +- Having many branches can be confusing. + + +### Fixing a release + +In case a particular release (that's not the latest release) needs to be fixed, a separate “fix release branch” is created. +Such a fix branch starts at the commit tagged for that particular release, and is named `fix/`. +Typically, a fix release version increments the patch part of the semver version number. +A fix branch is _never_ merged back into the `main` branch. +A fix release branch is (considered to be) released by tagging the appropriate commit as ``. + From 0ff13a693421033c9967b4ceb663e6e0fd21ed2a Mon Sep 17 00:00:00 2001 From: Meinte Boersma Date: Wed, 17 Nov 2021 10:43:39 +0100 Subject: [PATCH 3/7] Explain more about the separate steps. --- VERSIONING.md | 34 +++++++++++++++++++++++++++++----- 1 file changed, 29 insertions(+), 5 deletions(-) diff --git a/VERSIONING.md b/VERSIONING.md index bb2f5c7..e17c7f7 100644 --- a/VERSIONING.md +++ b/VERSIONING.md @@ -4,6 +4,7 @@ This file documents the versioning process. Versioning of this Git repository is organised as a simplified [Git flow](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow) (or [see here](https://medium.com/@patrickporto/4-branching-workflows-for-git-30d0aaee7bf)). The `main` branch is the _only_ primary branch, and therefore also serves as the _default branch_ for GitHub. + The version history is organised around **releases**. Each release is identified through a [semver version number](https://semver.org/). @@ -11,16 +12,39 @@ Each release is identified through a [semver version number](https://semver.org/ ## Releasing Releases are prepared in branches named `release/`. -After preparation has finished, a _Pull Request_ (PR) from the release branch into `main` is created. -This PR serves as the trigger a code review for that release, possibly leading to further work being done in that release branch. +After preparation has finished, a _Pull Request_ (PR) from the release branch into `main` is created on GitHub. +That can e.g. be done by clicking the “New Pull Request” button on the [branches page](https://github.com/ehn-dcc-development/ehn-dcc-valuesets/branches). + +Such a PR serves as the trigger a code review for that release. +That possibly leads to discussion conducted inside the PR page, and further work being committed to that release branch. After enough reviewers have approved the PR, it can be merged into `main`. Merging the PR is done through “rebase + merge commit”, _without_ fast-forwarding. -That keeps the history very clean, and tidy - linear, with the incremental work done for each release clearly identifiable. +On GitHub, that corresponds to the “Merge pull request” option, rather than the “Squash and merge”, or the “Rebase and merge” options. +On the commandline, it's: + + $ git checkout main + $ git pull + $ git merge release/ --no-ff + +That keeps the history very clean, and tidy - “linear”, with the incremental work done for each release clearly identifiable. After merging the PR for a release into `main`, the merge commit is tagged as ``. +That can be done on the commandline as follows (assuming the `main` branch is currently checked out): + + $ git tag + $ git push --tags + +It's advisable to rebase a release branch manually, and check it afterwards, as there's no guarantee that a conflict-free automatic rebase is syntactically, or semantically correct. +On the commandline, that's (assuming the release branch is currently checked out): + + $ git rebase main + +Doing an _interactive_ rebase by adding the flag `--interactive` to the `rebase` command usually makes this process more understandable, relatively free of pain, and you can clean the commits up a bit, if you like. +Tools such as [Fork](https://git-fork.com/) help even more. + +After a manual rebase, the rebased branch has to be force-pushed, using: -It's advisable to rebase a release branch manually, as there's no guarantee that a conflict-free automatic rebase is syntactically, or semantically correct. -After a manual rebase, the rebased branch has to be force-pushed. + $ git push --force The release branch can be deleted after merging the PR, for the following reasons: From 99d39f5e3cb017ae7a9359d289a5362793ece3fe Mon Sep 17 00:00:00 2001 From: Meinte Boersma Date: Thu, 18 Nov 2021 13:40:09 +0100 Subject: [PATCH 4/7] Update change log for this branch. --- CHANGELOG.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index c8c923d..1f6d809 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -2,6 +2,8 @@ ## Release 2.4.0 +* Change the versioning process, and document it in [`VERSIONING.md`](./VERSIONING.md). + ## Release 2.3.0 From ab51f866eb72f8d9829dd8387cbf505d9752b201 Mon Sep 17 00:00:00 2001 From: Meinte Boersma Date: Thu, 18 Nov 2021 16:28:05 +0100 Subject: [PATCH 5/7] (Small thing: fix a formulation w.r.t. PR merge options.) --- VERSIONING.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/VERSIONING.md b/VERSIONING.md index e17c7f7..57023af 100644 --- a/VERSIONING.md +++ b/VERSIONING.md @@ -20,7 +20,7 @@ That possibly leads to discussion conducted inside the PR page, and further work After enough reviewers have approved the PR, it can be merged into `main`. Merging the PR is done through “rebase + merge commit”, _without_ fast-forwarding. -On GitHub, that corresponds to the “Merge pull request” option, rather than the “Squash and merge”, or the “Rebase and merge” options. +On GitHub, that corresponds to the “Create a merge commit” option next to the “Merge pull request” button, rather than the “Squash and merge”, or the “Rebase and merge” options. On the commandline, it's: $ git checkout main From 520a12d91310a7671460d1971d924094d8864174 Mon Sep 17 00:00:00 2001 From: Meinte Boersma Date: Thu, 2 Dec 2021 09:30:02 +0100 Subject: [PATCH 6/7] update for value set guidelines document v1.6 --- CHANGELOG.md | 6 ++++++ vaccine-mah-manf.json | 7 +++++++ vaccine-medicinal-product.json | 7 +++++++ 3 files changed, 20 insertions(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index 1f6d809..9ae554a 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -4,6 +4,12 @@ * Change the versioning process, and document it in [`VERSIONING.md`](./VERSIONING.md). +* Update to eHN guidelines document for value sets, version 1.6: + 1. New vaccine: “MVC COVID-19 vaccine“, ID'd as “MVC-COV1901”. + 2. New manufacturer (for the new vaccine): “Medigen Vaccine Biologics Corporation”, ID'd as “ORG-100033914”. + + The [guidelines document v1.6 has been adopted and published](https://ec.europa.eu/health/sites/default/files/ehealth/docs/digital-green-value-sets_en.pdf) through the [eHealth network page on the EU DCC](https://ec.europa.eu/health/ehealth/covid-19_en). + ## Release 2.3.0 diff --git a/vaccine-mah-manf.json b/vaccine-mah-manf.json index 9720a1d..44b74dd 100644 --- a/vaccine-mah-manf.json +++ b/vaccine-mah-manf.json @@ -148,6 +148,13 @@ "active": true, "system": "http://ec.europa.eu/temp/vaccinemanufacturer", "version": "1.5" + }, + "ORG-100033914": { + "display": "Medigen Vaccine Biologics Corporation", + "lang": "en", + "active": true, + "system": "https://spor.ema.europa.eu/v1/organisations", + "version": "1.6" } } } diff --git a/vaccine-medicinal-product.json b/vaccine-medicinal-product.json index 980eac6..f1185ea 100644 --- a/vaccine-medicinal-product.json +++ b/vaccine-medicinal-product.json @@ -141,6 +141,13 @@ "active": true, "system": "http://ec.europa.eu/temp/vaccineproductname", "version": "1.5" + }, + "MVC-COV1901": { + "display": "MVC COVID-19 vaccine", + "lang": "en", + "active": true, + "system": "http://ec.europa.eu/temp/vaccineproductname", + "version": "1.6" } } } From 2223aac3181b033513873e9aff912dcaa21e1be8 Mon Sep 17 00:00:00 2001 From: Meinte Boersma Date: Thu, 2 Dec 2021 10:35:50 +0100 Subject: [PATCH 7/7] empty version attribute of added entry of SPOR manufacturer --- vaccine-mah-manf.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/vaccine-mah-manf.json b/vaccine-mah-manf.json index 44b74dd..967c75b 100644 --- a/vaccine-mah-manf.json +++ b/vaccine-mah-manf.json @@ -154,7 +154,7 @@ "lang": "en", "active": true, "system": "https://spor.ema.europa.eu/v1/organisations", - "version": "1.6" + "version": "" } } }