Bug #1078
Issue with patch version vs revision number
Status: | Resolved | Start date: | 07/12/2012 | |
---|---|---|---|---|
Priority: | Normal | Due 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
- 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.