Development

Information on Rundeck Development

• 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:

Branches

• [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.

Documentation

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

Performing releases

Notes on performing release for version x.y

1. create release-x.y branch from development
2. update version numbers
3. build and test release candidate version
4. update RELEASE.md file with release notes, thank contributors
5. merge to master
6. tag release vx.y
7. build from tag vx.y and release x.y
8. copy distribution files to s3 (and bintray?)
9. update rundeck-docs repo Rundeck-docs
10. update rundeck.org site with github pages Rundeck-site
11. update rundeck.org site with rpms for yum repo Rundeck-repo
12. upload artifacts to sonatype nexus repo

Maintenance

Notes on maintenance branches for version x.y(.z)

1. create maint-x.y branch from release tag branch (e.g. tag "v1.2")
2. create maint-x.y.z branch from maint-x.y
3. update version numbers
4. dev, build, test
5. perform bugfix merges separately to downstream development/release branches as appropriate (not to master)
6. merge maint-x.y.z into maint-x.y
7. tag release vx.y.z: git tag -a vx.y.z
8. build from tag vx.y.z and release x.y.z
9. copy dist files and update site as above