Skip to content

Commit

Permalink
master -> main
Browse files Browse the repository at this point in the history
  • Loading branch information
nllong committed Sep 30, 2021
1 parent 7a81b02 commit 2ad8ee4
Show file tree
Hide file tree
Showing 2 changed files with 4 additions and 4 deletions.
6 changes: 3 additions & 3 deletions docs/release_instructions.md
Original file line number Diff line number Diff line change
Expand Up @@ -16,15 +16,15 @@ Follow the steps below when releasing a new version
* Run the change_log.rb script (e.g., ruby src/change_log.rb -t abcdefghijklmnopqrstuvwxyz -s 2019-12-21). The date range must span from the last official release (ie don't start at a pre-release) until the current date.
* Copy the results of this into the CHANGELOG. Remove items that are not useful to an end user such as version bumps, formatting, etc.

* Create a Pull Request into `master`
* Create a Pull Request into `main`
* Mark the PR with an `ignore` label to prevent the PR from being added to future change logs.
* Merge the PR

### Tag and release

Check out master locally, pull changes, and create a tag and push it
Check out main locally, pull changes, and create a tag and push it
```bash
git checkout master && git pull
git checkout main && git pull
git tag -a v<version> -m "<message>" [SHA]
```
Where `v<version>` is a valid [semantic version](https://semver.org/) (e.g., `v1.2.3` or `v1.2.3-pr.1`) and `<message>` is the tagging message (e.g. "First official release"). See [Versioning](versioning.md) for more information.
Expand Down
2 changes: 1 addition & 1 deletion proposals/2020/BuildingSync Versioning.md
Original file line number Diff line number Diff line change
Expand Up @@ -34,6 +34,6 @@ These are the changes that require a new PATCH version. This would include chang
### Version management
I propose BuildingSync supports the two most recent MAJOR versions at a time. Support for a version means it will receive all new non-breaking changes (ie MINOR and PATCH changes).

BuildingSync should maintain two branches for each MAJOR version, develop and master. For example, for versions 2 and 3, you could have `develop-v2`, `master-v2`, `develop-v3` and `master-v3`. All releases (ie tags) are made off of the `master` branches. When ready for a new release, the maintainer merges the develop branch into master, then tags the last commit.
BuildingSync should maintain two branches for each MAJOR version, develop and main. For example, for versions 2 and 3, you could have `develop-v2`, `main-v2`, `develop-v3` and `main-v3`. All releases (ie tags) are made off of the `main` branches. When ready for a new release, the maintainer merges the develop branch into main, then tags the last commit.

To add a non-breaking change to the currently supported versions, the developer applies it to one of the develop branches then cherry picks or manually transfers the changes to the other develop branch.

0 comments on commit 2ad8ee4

Please sign in to comment.