Difference between revisions of "Continuous Integration: Developer"

From Gcube Wiki
Jump to: navigation, search
(Dependencies' version)
(Release preparation steps)
 
(10 intermediate revisions by 2 users not shown)
Line 5: Line 5:
  
 
= Dependencies' version =
 
= Dependencies' version =
The dependencies listed on the pom must be one of the following:
+
'''At release time''', the dependencies listed on the pom must be in one of the following formats:
1)  non SNAPSHOT, if a fixed version is requested. E.g.:
+
 
** 1.0
+
1)  a fixed version (without the -SNAPSHOT qualifier). E.g.:
 +
* 1.0
 +
* 1.1
 +
* ...
  
 
OR
 
OR
  
 
2) a range with the lower limit without the SNAPSHOT qualifier. E.g.:
 
2) a range with the lower limit without the SNAPSHOT qualifier. E.g.:
** [1.0, 1.3]
+
* [1.0, 1.3]
** [1.0, 1.3-SNAPSHOT)
+
* [1.0, 1.3-SNAPSHOT)
** [1.0, 2.0]
+
* [1.0, 2.0]
** [1.0, 2.0-SNAPSHOT)
+
* [1.0, 2.0-SNAPSHOT)
 +
* ...
  
For instance, the [1.0, 2.0-SNAPSHOT) will resolve against any version prior to 2.0-SNAPSHOT. Using [1.0, 2.0) will instead INCLUDE 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 obviously not visible during the release build.
  
= Tagging Master =
+
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.
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 [[Tags#Rules|tag]] the ''master'' branch.
+
  
 
= Creating a Release from the Tag=
 
= Creating a Release from the Tag=
See [[Tags#Released_Tags| Released Tags]].
+
 
 +
The tag procedure now is done automatically. The old activities were described here: [[Tags#Released_Tags| Released Tags]].
 +
 
 +
= Release integration steps=
 +
 
 +
See [[Release_Integration | Release Steps]].
  
 
''Back to the [[Continuous_Integration_procedure_(2019) | CI guide]].''
 
''Back to the [[Continuous_Integration_procedure_(2019) | CI guide]].''
  
 
[[Category:Continuous_Integration]]
 
[[Category:Continuous_Integration]]

Latest revision as of 18:38, 24 November 2020

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

Creating a Release from the Tag

The tag procedure now is done automatically. The old activities were described here: Released Tags.

Release integration steps

See Release Steps.

Back to the CI guide.