feat: clarify major release steps - #937
Conversation
ntarocco
left a comment
There was a problem hiding this comment.
Thank you for clarifying all this. I have added a few comments to make sure that the text is well understood by everyone.
| [maintenance-policy](../../releases/maintenance-policy.md). The development is | ||
| done on betaXX.devXX tags on master. Since invenio-app-rdm represents the | ||
| product InvenioRDM it uses a slightly different versioning schema. It still | ||
| follows the semver rules of versioning, but not on he major versions but on the |
There was a problem hiding this comment.
| follows the semver rules of versioning, but not on he major versions but on the | |
| follows the semver rules of versioning, but not on the major versions |
this sentence is difficult to understand with the double but, can you please rephrase it?
| product InvenioRDM it uses a slightly different versioning schema. It still | ||
| follows the semver rules of versioning, but not on he major versions but on the | ||
| beta versions. This means: releasing a new major version (e.g. v14.0) starts on | ||
| the master branch the tagging of beta versions (e.g. v15.0.0b0.dev0). The new |
There was a problem hiding this comment.
What do you mean with the master branch the tagging of beta versions?
| ### Module releases | ||
|
|
||
| Doing a new major release of a module starts a major release chain. A module | ||
| supports only 1 major version of another module. This means doing a major break |
There was a problem hiding this comment.
| supports only 1 major version of another module. This means doing a major break | |
| supports only 1 major version of another module. This means doing a major release |
| in a low level package as `invenio-db` starts a long major release chain up to | ||
| invenio-app-rdm. | ||
|
|
||
| TODO: picture of the graph? |
There was a problem hiding this comment.
Not sure that a picture is needed here.
|
|
||
| ### Initial iteration | ||
| The product release cycle starts with the release of the major version. This | ||
| means that from the date of the major version the new development cycly starts. |
There was a problem hiding this comment.
| means that from the date of the major version the new development cycly starts. | |
| means that from the date of the major version a new development cycle starts. |
| ### Initial iteration | ||
| The product release cycle starts with the release of the major version. This | ||
| means that from the date of the major version the new development cycly starts. | ||
| The release should take place in the first 2 weeks in July. The feature freeze |
There was a problem hiding this comment.
| The release should take place in the first 2 weeks in July. The feature freeze | |
| A major release normally takes place in July. The features freeze |
| in the first two weeks of June. The considering for feature freeze PR's deadline | ||
| takes place in the first weeks of April. |
There was a problem hiding this comment.
The last sentence is not very clear to me. Could you please clarify what is happening n April?
| in the first two weeks of June. The considering for feature freeze PR's deadline | |
| takes place in the first weeks of April. | |
| in June. The considering for feature freeze PR's deadline takes place in the first weeks of April. |
| The master branch will get a new major release. Yes it could be that the | ||
| master branch will get a major version without any real changes on the master | ||
| branch and therefor not follow semver in some points. But for the product | ||
| InvenioRDM and it's further development it is easier to do it that way. It | ||
| enables to merge breaking changes directly after the feature freeze and not | ||
| affecting the release of the product. |
There was a problem hiding this comment.
| The master branch will get a new major release. Yes it could be that the | |
| master branch will get a major version without any real changes on the master | |
| branch and therefor not follow semver in some points. But for the product | |
| InvenioRDM and it's further development it is easier to do it that way. It | |
| enables to merge breaking changes directly after the feature freeze and not | |
| affecting the release of the product. | |
| The master branch will get a new major release, even without significant changes (in this case, semver is not strictly followed). This approach allows merging unrelated breaking changes after the features freeze, without affecting an ongoing release. |
| Bugfixes and features are developed against the master branch and merged into | ||
| that branch first. Then the bugfix or feature is backported to the `maint-vX.Y` | ||
| branch. |
There was a problem hiding this comment.
| Bugfixes and features are developed against the master branch and merged into | |
| that branch first. Then the bugfix or feature is backported to the `maint-vX.Y` | |
| branch. | |
| Bugfixes and features are developed from and merged into the master branch. Then, they are backported to the `maint-vX.Y` branch. |
fenekku
left a comment
There was a problem hiding this comment.
v14 cleanup
I think I understand what is described, but it is hard to parse in part because the original file is lacking a clearer cookbook/how-to style. By providing any information outside these steps as asides in info boxes, we can make this a more straightforward recipe with scattered explanations.
I don't consider this a blocker for v14 docs, so placing it aside for now.
| - an instance template, [cookiecutter-invenio-rdm](https://github.com/inveniosoftware/cookiecutter-invenio-rdm) | ||
| - an application, [invenio-app-rdm](https://github.com/inveniosoftware/invenio-app-rdm) |
There was a problem hiding this comment.
Since the 2 are merged below, would merge here too:
| - an application: the combination of an instance template, [cookiecutter-invenio-rdm](https://github.com/inveniosoftware/cookiecutter-invenio-rdm) | |
| and the main module [invenio-app-rdm](https://github.com/inveniosoftware/invenio-app-rdm) collecting and configuring the others |
| cookiecutter-invenio-rdm. This branch is used when `invenio-cli init -c v14.0` | ||
| is used to init a new InvenioRDM instance) | ||
|
|
||
| A new major version of invenio-app-rdm is released once a year. see |
There was a problem hiding this comment.
| A new major version of invenio-app-rdm is released once a year. see | |
| A new major version of invenio-app-rdm is released once a year. See the |
| is used to init a new InvenioRDM instance) | ||
|
|
||
| A new major version of invenio-app-rdm is released once a year. see | ||
| [maintenance-policy](../../releases/maintenance-policy.md). The development is |
There was a problem hiding this comment.
| [maintenance-policy](../../releases/maintenance-policy.md). The development is | |
| [maintenance-policy](../../releases/maintenance-policy.md). Development is |
| A new major version of invenio-app-rdm is released once a year. see | ||
| [maintenance-policy](../../releases/maintenance-policy.md). The development is | ||
| done on betaXX.devXX tags on master. Since invenio-app-rdm represents the | ||
| product InvenioRDM it uses a slightly different versioning schema. It still |
There was a problem hiding this comment.
| product InvenioRDM it uses a slightly different versioning schema. It still | |
| product InvenioRDM it uses a slightly different versioning schema than other modules. It still |
No description provided.