Added DEVELOPING.md to include versioning process steps #127

Manually merged
sloum merged 3 commits from release-process-information into develop 2020-01-23 05:46:25 +00:00
2 changed files with 68 additions and 5 deletions
Showing only changes of commit 2b231184d8 - Show all commits

67
DEVELOPING.md Normal file
View 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..."
```
Review

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).

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).
Review

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).

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).
Review

I think that is a good call. I would not consider them full releases. Development releases is a good term.

I think that is a good call. I would not consider them full releases. Development releases is a good term.
Release information should also be added to the [tildegit releases page](https://tildegit.org/sloum/bombadillo/releases).

View File

@ -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