Added DEVELOPING.md to include versioning process steps #127
67
DEVELOPING.md
Normal file
67
DEVELOPING.md
Normal file
|
@ -0,0 +1,67 @@
|
|||
# Developing Bombadillo
|
||||
|
||||
## Getting Started
|
||||
|
||||
Following the standard install instructions should lead you to have nearly everything you need to commence development. The only additions to this are:
|
||||
|
||||
- To be able to submit pull requests, you will need to fork this repository first.
|
||||
- The build process must be tested with Go 1.11 to ensure backward compatibility. This version can be installed as per the [Go install documentation](https://golang.org/doc/install#extra_versions). Check that changes build with this version using `make test`.
|
||||
- Linting must be performed on new changes using `gofmt` and [golangci-lint](https://github.com/golangci/golangci-lint)
|
||||
|
||||
|
||||
## How changes are made
|
||||
|
||||
A stable version of Bombadillo is kept in the default branch, so that people can easily clone the repo and get a good version of the software.
|
||||
|
||||
New changes are introduced to the **develop** branch.
|
||||
|
||||
Changes to the default branch occur as part of the software release process. This usually occurs when:
|
||||
|
||||
- there are a set of changes in **develop** that are good enough to be considered stable.
|
||||
- an urgent issue is identified in the stable version that requires immediate changes
|
||||
|
||||
|
||||
### Process for introducing a new change
|
||||
|
||||
Please refer to our [notes on contributing](README.md#contributing) to get an understanding of how new changes are initiated, the type of changes accepted and the review process.
|
||||
|
||||
1. Create a new feature branch based on the **develop** branch.
|
||||
1. Raise a pull request (PR) targeting the **develop** branch.
|
||||
1. The PR is reviewed.
|
||||
1. If the PR is approved, it is merged.
|
||||
1. The version patch number is incremented.
|
||||
|
||||
|
||||
### Incrementing the version number
|
||||
|
||||
Version numbers are comprised of three digits: major version number, minor version number, and patch number.
|
||||
|
||||
Each new change added to **develop** should increment the patch number. For example, version 2.0.1 would become 2.0.2. After the change is merged from the feature branch to **develop**:
|
||||
|
||||
```shell
|
||||
# ensure everything is up to date and in the right place
|
||||
git checkout develop
|
||||
git pull
|
||||
|
||||
# get the commit ID for the recent merge
|
||||
git log
|
||||
|
||||
# get the current version number
|
||||
git tag
|
||||
|
||||
# add the incremented version number to the commit-id, for example:
|
||||
git tag 2.0.2 abcdef
|
||||
```
|
||||
|
||||
As part of the software release process, any part of the version number may change:
|
||||
- Urgent changes increment the **patch** number
|
||||
- A set of small changes increments the **minor** version number
|
||||
- A significant change to large parts of the application increments the **major** version number
|
||||
|
||||
The process is very similar to the above commands, however the final command should include an annotation:
|
||||
|
||||
```shell
|
||||
git tag 2.1.0 abdef -a "This version adds several new features..."
|
||||
```
|
||||
|
||||
|
||||
Release information should also be added to the [tildegit releases page](https://tildegit.org/sloum/bombadillo/releases).
|
|
@ -127,11 +127,7 @@ The maintainers use the [tildegit](https://tildegit.org) issues system to discus
|
|||
|
||||
## Development
|
||||
|
||||
Following the standard install instructions should lead you to have nearly everything you need to commence development. The only additions to this are:
|
||||
|
||||
- To be able to submit pull requests, you will need to fork this repository first.
|
||||
- The build process must be tested with Go 1.11 to ensure backward compatibility. This version can be installed as per the [Go install documentation](https://golang.org/doc/install#extra_versions). Check that changes build with this version using `make test`.
|
||||
- Linting must be performed on new changes using `gofmt` and [golangci-lint](https://github.com/golangci/golangci-lint)
|
||||
See [DEVELOPING.md](DEVELOPING.md) for information on how changes to Bombadillo are made, along with other technical information for developers.
|
||||
|
||||
## License
|
||||
|
||||
|
|
Loading…
Reference in New Issue
Block a user
In general I have been treating patch version changes as changes that will eventually get to master as part of either a minor version or major version merge, but the patches will be versioned as part of the develop branch (master should not generally have things on it with a patch other than 0, unless there is an error fix or the like).
So patches accrue on develop and are listed on the releases tab (but only as minor releases - since they ahve tags tildegit considers it a release of some sort) so people wanting latest greatest can pull those tags. Once enough patches build up develop will get merged into master and the minor version will be updated and the patch reset to 0.
Major versions are akin to python going from 2 - 3 and will not happen often at all (potentially many years in between).
OK, I think we have the same understanding on this, but the way I've written it makes it seem that new changes merged to develop aren't considered as releases. Is that your impression as well?
The document can be amended to indicate new changes merged to develop are still part of the release process, but are "development releases" (or a different name).
I think that is a good call. I would not consider them full releases. Development releases is a good term.