-
Notifications
You must be signed in to change notification settings - Fork 922
Development
Damon Edwards edited this page Jun 19, 2019
·
17 revisions
- Developer Guidelines - For information about submitting pull requests
- Obtaining Source - For how to get a copy of the Rundeck source code.
- Building and Testing - For information about building and running tests.
Information on git branches and release process is below:
- [master] - cutting edge development, please branch from here if you wish to submit patches
- [release-x.y] - x.y release path - open until final bugs are completed and x.y is released. it will be merged to master at that point (releases)
- [maint-x.y] - x.y maintenance path
Other branches are transient at this time.
As of Rundeck 3.0.x development cycle (2018-05), docs have moved to a separate repository: https://github.com/rundeck/docs instead of residing in this main source repo.
to add/update docs for a release A.B.C, such as "3.0.1":
fork/clone the docs repo https://github.com/rundeck/docs and branch from the "A.B.x" branch, for example "3.0.x"
git clone -b 3.0.x https://github.com/rundeck/docs rundeck-docs
make a branch from the 3.0.x branch
git checkout -b my-changes
make changes, commit, push your branch, make a PR to https://github.com/rundeck/docs repo against the correct source branch such as 3.0.x
Notes on performing release for version x.y
- create release-x.y branch from development
- update version numbers
- build and test release candidate version
- update RELEASE.md file with release notes, thank contributors
- merge to master
- tag release vx.y
- build from tag vx.y and release x.y
- copy distribution files to s3 (and bintray?)
- update rundeck-docs repo Rundeck-docs
- update rundeck.org site with github pages Rundeck-site
- update rundeck.org site with rpms for yum repo Rundeck-repo
- upload artifacts to sonatype nexus repo
Notes on maintenance branches for version x.y(.z)
- create maint-x.y branch from release tag branch (e.g. tag "v1.2")
- create maint-x.y.z branch from maint-x.y
- update version numbers
- dev, build, test
- perform bugfix merges separately to downstream development/release branches as appropriate (not to master)
- merge maint-x.y.z into maint-x.y
- tag release vx.y.z:
git tag -a vx.y.z
- build from tag vx.y.z and release x.y.z
- copy dist files and update site as above