We need to release our tools and libraries in a way that is easy to use and contribute.
- github.com for issues and pull requests
- git for version control
- Git branching model
- Git Release management[?]
Branches:
- master
- production ready, latest stable release
- default branch for
git clone
- merge from hotfix or release branches
- no PRs?
- hotfix branches
- r0.1.0[-hotfix1]
- bug fixes to master
- merge from master
- release branches
- r0.1.0[-rc1] - release candidate
- r0.2.0 - release branch
- allows for bug fixes to be applied to a release
- merge from develop
- develop (could be called
next
)- latest development changes
- merge from hotfix (forward-porting)
- merge from feature branches
- clone this branch for small changes and bug fixes
- feature branches
- new features in development that contain breaking changes
- merge bugs from develop (from time to time, prior to merge to develop)
Do we need this? We are not proposing to distribute binaries, so we don't need to tag releases.
We should ship bootless
binaries (with versions to match upstream)
A few notes from me:
main
should be the release branch.hotfix/some-hotfix-name
orfeature/feature-name
displays very fine on some UI tools such as Sourcetree. This way one is able to display all hotfixes/features/etc. under a directory on the UI.r
? I sawv
before (Parity uses it), but I think it's unnecessary. Plain version number is enough imo.main
ordevelop
should always be kept rebased on the origin branch so that we keep the correct history of commits when we merge.