srenblad/artiq
1
0
Fork 0
forked from M-Labs/artiq
Code Pull Requests Activity

move RELEASING into DEVELOPER_NOTES

Browse Source
This commit is contained in:
Sebastien Bourdeauducq 2017-12-07 13:24:06 +08:00
parent e5d8314aa7
commit 825f1ff1ce
2 changed files with 27 additions and 26 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

27
DEVELOPER_NOTES.rst
View File

@ -1,3 +1,30 @@
Release process
===============
Maintain ``RELEASE_NOTES.rst`` with a list of new features and API changes in each major release.
Major releases
--------------
1. Create branch release-X from master.
2. Tag the next commit in master X+1.0.dev.
3. Ensure that release versions of all packages required are available under the ``main`` label in conda. Ensure that new packages in ``main`` do not break older ARTIQ releases.
4. In the release-X branch, remove any unfinished features.
5. Test and fix any problems found. Apply fixes to both master and release-X.
6. If you have willing testers for release candidates, tag X.0rc1 in the release-X branch (generally use signed annotated tags, i.e. ``git tag -sa X.0rc1``), have it build, and point testers there. Iterate over the previous points with new release candidates if necessary.
7. Tag X.0 in the release-X branch, build it, and copy its packages to ``main`` channel.
8. Mint a new DOI from Zenodo and update the README/introduction.
9. Update the m-labs.hk/artiq/manual redirect to point to m-labs.hk/artiq/manual-release-X (edit /artiq/.htaccess).
10. "Draft a new release" and close the milestone on GitHub.
Minor (bugfix) releases
-----------------------
1. Backport bugfixes from the master branch or fix bugs specific to old releases into the currently maintained release-X branch(es).
2. When significant bugs have been fixed, tag X.Y+1.
3. To help dealing with regressions, no new features or refactorings should be implemented in release-X branches. Those happen in the master branch, and then a new release-X+1 branch is created.
4. "Draft a new release" and close the milestone on GitHub.
Sharing development boards
==========================

26
RELEASING.rst
View File

@ -1,26 +0,0 @@
Release process
===============
Maintain ``RELEASE_NOTES.rst`` with a list of new features and API changes in each major release.
Major releases
--------------
1. Create branch release-X from master.
2. Tag the next commit in master X+1.0.dev.
3. Ensure that release versions of all packages required are available under the ``main`` label in conda. Ensure that new packages in ``main`` do not break older ARTIQ releases.
4. In the release-X branch, remove any unfinished features.
5. Test and fix any problems found. Apply fixes to both master and release-X.
6. If you have willing testers for release candidates, tag X.0rc1 in the release-X branch (generally use signed annotated tags, i.e. ``git tag -sa X.0rc1``), have it build, and point testers there. Iterate over the previous points with new release candidates if necessary.
7. Tag X.0 in the release-X branch, build it, and copy its packages to ``main`` channel.
8. Mint a new DOI from Zenodo and update the README/introduction.
9. Update the m-labs.hk/artiq/manual redirect to point to m-labs.hk/artiq/manual-release-X (edit /artiq/.htaccess).
10. "Draft a new release" and close the milestone on GitHub.
Minor (bugfix) releases
-----------------------
1. Backport bugfixes from the master branch or fix bugs specific to old releases into the currently maintained release-X branch(es).
2. When significant bugs have been fixed, tag X.Y+1.
3. To help dealing with regressions, no new features or refactorings should be implemented in release-X branches. Those happen in the master branch, and then a new release-X+1 branch is created.
4. "Draft a new release" and close the milestone on GitHub.