Difference between revisions of "Continuous Integration: Developer"

From Gcube Wiki
Jump to: navigation, search
(Tagging Master)
(Tagging Master)
Line 24: Line 24:
  
 
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.
 
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 [[Tags#Rules|tag]] the ''master'' branch at the commit ID reported in the build report.
 
 
The commit is tagged twice:
 
* v<component version>
 
* r<Gcube Release number>
 
 
For example:
 
 
[[File:Git-release-tags.png|600px]]
 
  
 
= Creating a Release from the Tag=
 
= Creating a Release from the Tag=

Revision as of 04:42, 30 December 2019

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

See Released Tags.

Back to the CI guide.