OneStop is a data discovery system being built by CIRES researchers on a grant from the NOAA National Centers for Environmental Information. We welcome contributions from the community!
This project is maintained by cedardevs
Estimated Reading Time: 10 minutes
We have several google documents on this topic in Google Drive at Agile Project> Team Norms
.
master
contains changes being prepped for a release, with tags marking each release.
The master branch should be kept in a working state but represents the “bleeding edge”
version of the project. By “working” we mean it compiles, passes tests and results in
a deployable artifact.release/[version]
contains the existing release paths. These only deviate from the
release tagged on the master branch when hotfixes are required. A new release branch
should be created for every major version. Minor releases can be merged into their
major version branch. Patches should also be merged to their respective branch, but
follows a different work flow. Reference Hotfix Strategy for more
information.Temporary branches are used to work on features and major changes via the following steps:
Make a new branch off master
. As a naming convention, please follow the convention
in Google Drive at Agile Project> Team Norms> Foam Cat Team Norms
document. Do not to
use master
or the release/
or hotfix/
prefix:
git fetch origin
git checkout -b feature/foo origin/master
If the work is related to an issue, the branch is typically named <issue#>-short-description
,
for example “1404-dev_docs_pass2”, where the description is derived from the issue title.
Spaces are not allowed in branch names, so either hyphens or underscores can be used in their place.
Write code with tests!
Upon completion move the Github/Zenhub story into the Review column
Create a pull request. Please link with the story via “Linked issues”
The reviewer merges the pull request back into the master
branch and deletes the
working branch. Verify story in github/zenhub got moved to Closed column (may have to manually do).
Our version numbers follow the pattern of <major>.<minor>.<patch>
:
When all the features in master are ready for production, it is time to cut a release. A “release” is either a new major or minor version. For a patch, see the Hotfix Strategy documentation. Follow these steps to publish a release:
manageVersions.sh
script to get the version number throughout the project.v2.13.1
.
git tag <tag>
git push origin <tag>
release/[version]
, e.g. release/3.x
.manageVersions.sh
,
commit to directly to master (this is a small change, so no need for a PR).master
branch.