Skip to content
Browse files
Merge develop to branch 2393
  • Loading branch information
chasegawa committed Dec 7, 2022
2 parents f0b3462 + d20c531 commit 1d2f2f4258e3cc49aa660f5d9bdac2a546648e40
Showing 9 changed files with 829 additions and 9 deletions.
@@ -0,0 +1,32 @@
# Versioning policy

ShibUI versioning scheme is based on the [semantic versioning 2.0.0](

It follows the version format of the following form: `MAJOR.MINOR.PATCH` numbers where:

* MAJOR: Represents major software features and potential breaking changes
* MINOR: Represents backward-compatible software features
* PATCH: Backward-compatible software bug fixes, typically released outside of the normal release cycle

Together with semantic versioning numbers, the following labels are used to give hints about the state of release lifecycle. These labels are:

* M[number]: A milestone release (M1, M2, M3...) marks as significant progress milestone in a major release development. Milestone releases are not considered to be stable and are discouraged to be used in production.

* RC[number]: A release candidate (RC1, RC2, RC3...) is the last feature complete release before building a final generally available release. The purpose of release candidates is to give end users of the software a chance to do a test drive, to find and fix bugs before releasing a final version. To minimize code changes, only bug fixes should occur at this stage. Release candidate releases are not considered to be stable and are discouraged to be used in production.

At the very end of release process, the ShibUI development team will publish so called generally available releases which would be considered stable and targeted to be used in production.

In ShibUI software, some of the examples of release cycles are:

* Major database and data model changes, which would break backward compatibility during upgrades, would be characterized as `MAJOR` releases. In the same vein, major changes to the exposed Web Services APIs would be included in `MAJOR` release cycle.
* Any new added UI features that would not break major backward compatibility during upgrades would be characterized as `MINOR` feature releases.

Examples of version:

* `2.0.0-M1` - first milestone release of 2.0.0 major version (not stable)
* `2.0.0-RC1` - first release candidate of 2.0.0 major version (not stable)
* `2.0.0` - Major GA release of 2.0.0 line
* `2.0.1` - Patch release of 2.0.x line
* `2.1.0` - First minor feature release of 2.x line

@@ -160,7 +160,8 @@ class SeleniumSIDETest extends Specification {
'SHIBUI-1674: Verify advanced menu tooltips' | '/SHIBUI-1674-3.side'
'SHIBUI-2270: Verify property set CRUD' | '/SHIBUI-2270-1.side'
'SHIBUI-2270: Verify full property set' | '/SHIBUI-2270-2.side'
'SHIBUI-2394: Multiple levels of approval' | '/SHIBUI-2394.side'
'SHIBUI-2268: Verify Algorithm Filter' | '/SHIBUI-2268.side'
'SHIBUI-2269: Verify XML generation of external filters' | '/SHIBUI-2269.side'
'SHIBUI-2269: Verify XML generation of external filters' | '/SHIBUI-2269.side' // Leave this as the last test in order to keep the suite running without strange errors.
@@ -2502,7 +2502,7 @@
"id": "4dbf4b6f-7de9-49e1-a23f-ff748f5a986b",
"comment": "",
"command": "pause",
"target": "7000",
"target": "10000",
"targets": [],
"value": ""
}, {

0 comments on commit 1d2f2f4

Please sign in to comment.