Currently it is not clear how we handle incrementing the CPF version for clients.
Problems:
The CPF components do not verify that depended on components have the correct versions. The jenkinsjob uses the buildscript interface. CPFBuildscripts uses the CPFCMake interface. The components should check for the presence of compatible version. In the case of the CPFBuildscripts -> CPFCMake dependency that would be an argument to merge the two packages into one.
The build-infrastructure can only build jobs of the current cpf version. Upgrading the CPF version can introduce a barrier for building older revisions. The CPF should therefore implement a mechanism that allows running build-slaves that are able to run older versions of the build-job.
The post-receive triggers use the parameter interface of the job. This may cause problems when we push to branches that use an older CPF version.
Currently it is not clear how we handle incrementing the CPF version for clients.
Problems:
The CPF components do not verify that depended on components have the correct versions. The jenkinsjob uses the buildscript interface. CPFBuildscripts uses the CPFCMake interface. The components should check for the presence of compatible version. In the case of the CPFBuildscripts -> CPFCMake dependency that would be an argument to merge the two packages into one.
The build-infrastructure can only build jobs of the current cpf version. Upgrading the CPF version can introduce a barrier for building older revisions. The CPF should therefore implement a mechanism that allows running build-slaves that are able to run older versions of the build-job.
The post-receive triggers use the parameter interface of the job. This may cause problems when we push to branches that use an older CPF version.