[LU-1508] serially incrementing build number in the version for between-releases builds Created: 11/Jun/12 Updated: 29/May/17 Resolved: 29/May/17 |
|
| Status: | Resolved |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | Lustre 2.3.0, Lustre 2.1.2 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Minor |
| Reporter: | Brian Murrell (Inactive) | Assignee: | Minh Diep |
| Resolution: | Low Priority | Votes: | 0 |
| Labels: | None | ||
| Severity: | 3 |
| Rank (Obsolete): | 10486 |
| Description |
|
Currently, while we are building between releases, the version and release stay the same and the only difference from one build to the next is the git hash. Unfortunately, the git hash is not guaranteed to sort predictably from one release to another and as such it does not guarantee that build n+1 of the lustre packages will properly upgrade build n. What is needed is an postfix to the version/release that is guaranteed to sort predictably. This could be as simple as a serial number and can (and is in fact already in the versioning configure macro) actually be derived as the number of commits since the last git release tag was made (i.e. so it is always 1 on the first commit after a release tag – very handy). Alternatively it can just be a date/timestamp, either in "epoch" format or YYMMDDhhmm[ss]. But the point here is to enable RPM and yum to know that one build of packages is newer than another and as such it should upgrade the older ones with the newer ones. |
| Comments |
| Comment by Peter Jones [ 18/Jun/12 ] |
|
Minh Could you look into this when you have a chance? Peter |
| Comment by Minh Diep [ 25/Jun/12 ] |
|
I'll take a look. |