... | ... | @@ -96,26 +96,44 @@ The dependencies of miniff are captured in the following files. |
|
|
## Software versioning and Release management
|
|
|
(Under construction ...)
|
|
|
|
|
|
### Branch semantics
|
|
|
* **master**
|
|
|
Currently, miniff is in development phase. The master branch receives the changes for the next major/minor/patch release. To mark specific points in the development history, tags are created along with a release note. A release branch will be created from master once the required functionality is in master.
|
|
|
|
|
|
This repository uses [Semantic versioning](https://semver.org/).
|
|
|
|
|
|
### Development workflow
|
|
|
New issues -> feature branch -> Add changes, update changelog (unreleased) -> merge to master
|
|
|
Follow the below development workflow when adding new changes to miniff.
|
|
|
|
|
|
* Start with creating a new issue on the issue board for the changes you wish to add. This can be a new feature, enhancement or a bug fix.
|
|
|
|
|
|
### Workflow for creating a new release
|
|
|
* Create a new feature branch from master and add your changes in it.
|
|
|
```
|
|
|
git checkout -b <feature-abc> master
|
|
|
```
|
|
|
|
|
|
* If your changes involve addition/removal or version update of any of the miniff's dependencies, ensure that the change is done in the following files and is consistent.
|
|
|
* setup.py
|
|
|
* environment.yml
|
|
|
* requirements.txt
|
|
|
* docs/requirements.txt
|
|
|
* pyproject.toml
|
|
|
* gitlab-ci.yml
|
|
|
|
|
|
* Update CHANGELOG.md describing your changes as per [keep a changelog](https://keepachangelog.com/en/1.0.0/) format and associate them with a version number. Determine the version number as per the below convention from semantic versioning.
|
|
|
* Bump up the patch version if you are making a bug fix/minor enhancement,
|
|
|
* Bump up the minor version if you are adding new feature, functionality that is backwards compatible.
|
|
|
* bump up the major version if you are making ground breaking backwards incompatible changes.
|
|
|
|
|
|
* Bump up the version number in setup.py
|
|
|
|
|
|
* Bump up the version number in setup.py. Bump up the version number (major, minor or patch) as described below.
|
|
|
Tagging scheme: as per semantic versioning
|
|
|
`<MAJOR>.<MINOR>.<PATCH>`<br/>
|
|
|
For bug fixes, bump up the patch version, bump up the minor version when adding new features and bump up the major version when introducing major changes.
|
|
|
* Create a merge request towards master
|
|
|
* Create a tag on master, push the tag to remote master on the GitLab repo.
|
|
|
`git tag -a v<MAJOR>.<MINOR>.<PATCH> -m '<MESSAGE>'`
|
|
|
* Generate the source distribution and upload to PyPI as per the steps in
|
|
|
* We don’t need to locally test the source tarball or build the documentation separately. That is taken care of in the CI already.
|
|
|
* Upload the source archive for the new version on Zenodo, follow the steps as explained in the software citation section
|
|
|
* Ideally, make a merge request towards master when your changes are complete, i.e., all the required changes for a particular new major, minor or patch version that you intend to create are present in your feature branch. This ensure that master doesn't have a half baked new functionality/feature/bugfix at any point in time.
|
|
|
|
|
|
* After the feature branch is merged into master, create a tag on the master to mark the new major/minor/patch version and push the tag to the repository.
|
|
|
```
|
|
|
git tag -a x.y.z -m "release note"
|
|
|
```
|
|
|
```
|
|
|
git push origin x.y.z
|
|
|
```
|
|
|
|
|
|
* Upload the new version to PyPI and Zenodo following the steps lised in the sections Packaging miniff and uploading to PyPI and software citation respectively.
|
|
|
|
|
|
|