From 2b231184d89f971d06feb321ebdd46749611ad01 Mon Sep 17 00:00:00 2001 From: asdf Date: Wed, 8 Jan 2020 14:33:49 +1100 Subject: [PATCH 1/3] Added DEVELOPING.md to include versioning process steps --- DEVELOPING.md | 67 +++++++++++++++++++++++++++++++++++++++++++++++++++ README.md | 6 +---- 2 files changed, 68 insertions(+), 5 deletions(-) create mode 100644 DEVELOPING.md diff --git a/DEVELOPING.md b/DEVELOPING.md new file mode 100644 index 0000000..019f1d0 --- /dev/null +++ b/DEVELOPING.md @@ -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). diff --git a/README.md b/README.md index f965945..1b1af0f 100644 --- a/README.md +++ b/README.md @@ -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 From 6720b62276b4db778cffdc127576321ed858922f Mon Sep 17 00:00:00 2001 From: asdf Date: Wed, 8 Jan 2020 14:57:38 +1100 Subject: [PATCH 2/3] Added information regarding the VERSION file --- DEVELOPING.md | 24 +++++++++++++++--------- 1 file changed, 15 insertions(+), 9 deletions(-) diff --git a/DEVELOPING.md b/DEVELOPING.md index 019f1d0..b6ef58f 100644 --- a/DEVELOPING.md +++ b/DEVELOPING.md @@ -34,8 +34,14 @@ Please refer to our [notes on contributing](README.md#contributing) to get an un ### Incrementing the version number +This process is handled by maintainers after a change has been merged. + Version numbers are comprised of three digits: major version number, minor version number, and patch number. +The version number is incremented in the following situations: + +#### New changes + 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 @@ -46,22 +52,22 @@ git pull # get the commit ID for the recent merge git log -# get the current version number +# get the current version number (the highest number) git tag # add the incremented version number to the commit-id, for example: -git tag 2.0.2 abcdef +git tag 2.0.2 abcdef ``` +#### Release process + 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). +1. The version number in the VERSION file is incremented. This change is committed to the default branch. +1. The **develop** branch is merged to the default branch. +1. The commands from the New Changes section are followed, but the final command includes an annotation: `git tag 2.1.0 abdef -a "This version adds several new features..."` +1. Release information should also be added to the [tildegit releases page](https://tildegit.org/sloum/bombadillo/releases). From 3cf27b82ad90237856612e360950fe2b6a3ee162 Mon Sep 17 00:00:00 2001 From: asdf Date: Thu, 23 Jan 2020 13:48:38 +1100 Subject: [PATCH 3/3] Further review of release information --- DEVELOPING.md | 49 ++++++++++++++++++++----------------------------- 1 file changed, 20 insertions(+), 29 deletions(-) diff --git a/DEVELOPING.md b/DEVELOPING.md index b6ef58f..4b05842 100644 --- a/DEVELOPING.md +++ b/DEVELOPING.md @@ -13,12 +13,14 @@ Following the standard install instructions should lead you to have nearly every 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. +New changes are implemented to the **develop** branch as **development releases**. -Changes to the default branch occur as part of the software release process. This usually occurs when: +Changes are implemented to the default branch 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 + - There are a set of changes in **develop** that are good enough to be considered stable. + - This may be a **minor** set of changes for a **minor release**, or + - a large **major** change for **major release**. + - An urgent issue is identified in the stable version that requires an immediate **patch release**. ### Process for introducing a new change @@ -29,24 +31,18 @@ Please refer to our [notes on contributing](README.md#contributing) to get an un 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. +1. The version number is incremented, along with any other release activity. -### Incrementing the version number +### Process for incrementing the version number -This process is handled by maintainers after a change has been merged. - -Version numbers are comprised of three digits: major version number, minor version number, and patch number. - -The version number is incremented in the following situations: - -#### New changes - -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**: +The version number is incremented during a **development release**, **patch release**, and **minor** and **major releases**. This is primarily managed through git tags in the following way: ```shell -# ensure everything is up to date and in the right place -git checkout develop +# switch to the branch the release is being performed for +git checkout branch + +# ensure everything is up to date git pull # get the commit ID for the recent merge @@ -55,19 +51,14 @@ git log # get the current version number (the highest number) git tag -# add the incremented version number to the commit-id, for example: +# for a development release, add the incremented version number to the commit-id, for example: git tag 2.0.2 abcdef + +# for releases to the default branch, this tag can also be added with annotations +git tag 2.1.0 abdef -a "This version adds several new features..." ``` -#### Release process +Releases to the default branch also include the following tasks: -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 - -1. The version number in the VERSION file is incremented. This change is committed to the default branch. -1. The **develop** branch is merged to the default branch. -1. The commands from the New Changes section are followed, but the final command includes an annotation: `git tag 2.1.0 abdef -a "This version adds several new features..."` -1. Release information should also be added to the [tildegit releases page](https://tildegit.org/sloum/bombadillo/releases). +1. The version number in the VERSION file is incremented and committed. +1. Release information should also be verified on the [tildegit releases page](https://tildegit.org/sloum/bombadillo/releases).