Bug #1078

Issue with patch version vs revision number

Added by Anonymous almost 12 years ago. Updated over 11 years ago.

Status:ResolvedStart date:07/12/2012
Priority:NormalDue date:
Assignee:-% Done:

100%

Category:-
Target version:-

Description

In a short intermediate situation of a few days, we decided to build packages with the patch version to be the build number of the CI job. We recently switched to instead append the build number as revision behind major-minor-patch version.
This can cause problems, since the former built package like 0.1.17 (17 being the build number) is considered more recent by package managers then the version string we build now, which is something like 0.1.0-r17.
This prevents package managers from updating our packages, even if we continuously build new versions.

One possible (not nice) workaround could be to increase the patch version in the package cmake config to a number greater then the previous build number.

Any other ideas?

History

#1 Updated by Anonymous over 11 years ago

  • Status changed from New to Resolved
  • Assignee set to Anonymous
  • % Done changed from 0 to 100
For documentation: We choose to do the following:
  • As long as it is a trunk job, we attach -b$BUILD_NUMBER}
  • When it is releases, we attach -r$BUILD_NUMBER}

Since in debian arithmetic -r... is always > -b... the release package will always prioritized over the former trunk packages, regardless the actual build number.

Also available in: Atom PDF