You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The release process is automated in the following way:
2
-
1) With every build, the build process on Travis updates files with an appropriate version number before deployment into the database.
3
-
This is to confirm that the update of versions works properly.
4
-
2) When a build is executed on a branch named `release/v1.2.3-something` then additional steps are taken:
5
-
- the project version in files: `sonar-project.properties`, `VERSION` is updated from the version number derived from the release branch
6
-
- 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
7
-
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]+.*$`
8
-
- When a tag build is executed, the documentation is built and files are uploaded to the tag.
9
-
- The version number is derived from the tag name.
10
-
4) The release version does not provide access to unversioned source files (the default zip file from GitHub is empty).
11
-
The sources for release are provided in separate zip files delivered from the Travis build process.
1
+
The release process is semi-automated.
2
+
3
+
With every build, the build process on Travis updates files with an appropriate version number before deployment into the database.
4
+
This step is performed, to confirm that the update of versions works properly.
5
+
6
+
To create a release:
7
+
- create release branch and wait for release build to complete successfully
8
+
- merge release branch to master and wait for master build to complete successfully
9
+
- 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
10
+
11
+
The following will happen:
12
+
- build executed on branch `release/v1.2.3-[something]` updates files `sonar-project.properties`, `VERSION` with project version derived from the release branch name
13
+
- changes to those two files are committed and pushed back to release branch by Travis
14
+
- when a release is created, a new tag is added in on the repository and a tag build is executed
15
+
- the documentation for new release is published on `utplsql.github.io` and installation archives are added to the tag.
16
+
17
+
Note:
18
+
The released version does not provide access to un-versioned source files (the default zip file from GitHub is empty).
19
+
The sources for release are provided in separate zip files delivered from the Travis build process.
20
+
This is because we do not keep version in our source files in develop branch.
0 commit comments