Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Updated description of release process in releasing.md #498

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
jgebal merged 2 commits into from
Oct 23, 2017
Merged

Updated description of release process in releasing.md #498

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
57f4898
Updated description of release process in `releasing.md`
jgebal Aug 29, 2017
bcb3f3e
Merge branch 'develop' into feature/update_releasing.md
jgebal Oct 23, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
31 changes: 20 additions & 11 deletions development/releasing.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,11 +1,20 @@
The release process is automated in the following way:
1) With every build, the build process on Travis updates files with an appropriate version number before deployment into the database.
This is to confirm that the update of versions works properly.
2) When a build is executed on a branch named `release/v1.2.3-something` then additional steps are taken:
- the project version in files: `sonar-project.properties`, `VERSION` is updated from the version number derived from the release branch
- changes to those two files are committed and pushed - this should happen only once, when the release branch is initially created on the main repo
3) To create a release, just create a tag on the code to be released. The tag name must match the regex pattern: `^v[0-9]+\.[0-9]+\.[0-9]+.*$`
- When a tag build is executed, the documentation is built and files are uploaded to the tag.
- The version number is derived from the tag name.
4) The release version does not provide access to unversioned source files (the default zip file from GitHub is empty).
The sources for release are provided in separate zip files delivered from the Travis build process.
The release process is semi-automated.

With every build, the build process on Travis updates files with an appropriate version number before deployment into the database.
This step is performed, to confirm that the update of versions works properly.

To create a release:
- create release branch and wait for release build to complete successfully
- merge release branch to master and wait for master build to complete successfully
- create a release from the master branch using github web page and populate release description using information found on the issues and pull requests for release

The following will happen:
- build executed on branch `release/v1.2.3-[something]` updates files `sonar-project.properties`, `VERSION` with project version derived from the release branch name
- changes to those two files are committed and pushed back to release branch by Travis
- when a release is created, a new tag is added in on the repository and a tag build is executed
- the documentation for new release is published on `utplsql.github.io` and installation archives are added to the tag.

Note:
The released version does not provide access to un-versioned source files (the default zip file from GitHub is empty).
The sources for release are provided in separate zip files delivered from the Travis build process.
This is because we do not keep version in our source files in develop branch.