- A beta-release is not necessarily safe and stable but can be tested for qualifications/improvements.
- A stable-release is a release that passed a number of tests and that we declare stable.
Useful branches of the Git project:
- latest-release : branch going from one stable-release to the next.
- latest-beta: branch going from one beta-release to the next.
For simplicity and clarity, these branches connect commits that are all on the master branch.
### Producing a beta-release (project owner)
For simplicity and clarity, the latest-release branch connects commits that are all on the master branch.
We assume here that you have a new version of MyLabStocks on a dev server and that you are happy with it and want to make a release.
Steps when making a beta-release:
- Update seeders of functionality tables (for details and why, see above)
```sh
./gitfunctionalitytables.sh
```
- commit your changes
- merge to the master branch. For simplicity/clarity of this project, we don't want too many branches and things will be much simpler if all releases are on the master branch.
- Make a tag with a new version in format `vX.X.X-beta`
```sh
git tag -a vX.X.X-beta -m"version X.X.X-beta"# change with tag name of the new version
```
- Produce the release on Gitlab server. Indicate in **comments that it is a beta release**, and link it to milestones and any relevant information.
- Update branch beta-release
```sh
git checkout latest-beta
git merge vX.X.X-beta # change with tag name of the new version
```
- Upgrade a server (a VM machine) dedicated to qualification of beta releases (follow the upgrading instructions of the doc for administrators). On this upgraded instance, perform a few tests to see if all is ok.
### Producing a stable-release (project owner)
A stable release must be almost similar to a beta release, with minor changes, so that beta-testers have got time to report issues if there were any. If the latest beta release is very different from your current version, you must first release this new version as a beta-release (see above) and, after potential beta-testers (including you) are satisfied, modify it only slightly to release it as a stable one.
When releasing a stable-release:
Steps when making a release:
- Update seeders of functionality tables (for details and why, see above)
```sh
./gitfunctionalitytables.sh
```
- commit your changes
- merge to the master branch.
- Make a tag with a new version in format `vZ.Z.Z` # change with tag name of the new version
- Make a tag with a new version in format `vX.X.X`
```sh
git tag -a vZ.Z.Z-m"version Z.Z.Z"
git tag -a vX.X.X-m"version X.X.X"# change with tag name of the new version
```
- Produce the release on Gitlab server. Indicate in **comments that it is a beta release**, and link it to milestones and any relevant information.
- Update branch beta-release
```sh
git checkout latest-beta
git
- Produce the release on Gitlab server. Indicate in**comments that it is a stable release**, and link it to milestones and any relevant information.
- Update branch latest-release:
- Produce the release on Gitlab server. Indicate in **comments the major changes, the issues (with their ID) that were addressed**, and link it to milestones and any relevant information.
- Update branch latest-release
```sh
git checkout latest-release
git merge vZ.Z.Z # change with tag name of the new version
git merge vX.X.X# change with tag name of the new version
```
- Upgrade a server (a VM machine) dedicated to qualification of stable releases and make a few tests to see if all is ok.
- Upgrade a server (a VM machine) dedicated to qualification of new releases (follow the upgrading instructions of the doc for administrators). On this upgraded instance, perform a few tests to see if all is ok.
