Difference between revisions of "Continuous Integration: Developer"
Manuele.simi (Talk | contribs) (→Dependencies' version) |
Manuele.simi (Talk | contribs) (→Dependencies' version) |
||
| Line 5: | Line 5: | ||
= Dependencies' version = | = Dependencies' version = | ||
| − | + | '''At release time''', the dependencies listed on the pom must be in one of the following formats: | |
| − | 1) | + | 1) a fixed version (without the -SNAPSHOT qualifier). E.g.: |
* 1.0 | * 1.0 | ||
* 1.1 | * 1.1 | ||
| Line 21: | Line 21: | ||
* ... | * ... | ||
| − | + | The reason behind this type of range is to make sure snapshots are not required at release time. The build of the project would otherwise fail since the gcube-snasphots maven repository is not obviously not visible during the release build. | |
| + | |||
| + | A developer can use the dependencies' versions that best fit the development activity (even if it's suggested to always keep these formats to avoid a continuous switching) but must then comply to the formats on the master branch at release time. | ||
= Tagging Master = | = Tagging Master = | ||
Revision as of 21:25, 2 October 2019
Contents
POM version on master
Technically, the master branch must be releasable at any time.
When a gCube release is declared open by the Release Manager and until it is declared close, the artifact version in the POM on master MUST NOT have the -SNAPSHOT suffix.
Dependencies' version
At release time, the dependencies listed on the pom must be in one of the following formats:
1) a fixed version (without the -SNAPSHOT qualifier). E.g.:
- 1.0
- 1.1
- ...
OR
2) a range with the lower limit without the SNAPSHOT qualifier. E.g.:
- [1.0, 1.3]
- [1.0, 1.3-SNAPSHOT)
- [1.0, 2.0]
- [1.0, 2.0-SNAPSHOT)
- ...
The reason behind this type of range is to make sure snapshots are not required at release time. The build of the project would otherwise fail since the gcube-snasphots maven repository is not obviously not visible during the release build.
A developer can use the dependencies' versions that best fit the development activity (even if it's suggested to always keep these formats to avoid a continuous switching) but must then comply to the formats on the master branch at release time.
Tagging Master
When the gCube release is declared close by the Release Manager and if the release includes a new version of a component, the developer must tag the master branch.
Creating a Release from the Tag
See Released Tags.
Back to the CI guide.
