 |
 |
Toward your first question - I want the SHA1 available so I can easily go from output of `rpm -q` from a tester who is reporting an issue to a specific version of the code. Something like `4.6.1-1.master.91.gc41d4c1` gets closer; it works at a technical level, but runs afoul of RPM packaging standards - basically, once an official release is done, the release number (`1.master.91.gc41d4c1`) is meant to be utilized by the distributions. For example, `xrootd` in Fedora (https://koji.fedoraproject.org/koji/buildinfo?buildID=874518) had 8 rebuilds; this got the release number up to 9. So, since distros start the release number at `1` for official releases, it's become common to see pre-releases start with `0`. What about `4.6.1.1-0.master.91.gc41d4c1`? That meets the criteria of RPM versioning and keeps the release number prefixed with 0. We still have the problem of determining the "last release". `git describe` gets confused because we don't merge stable branches through master. Perhaps we really want "next release", not "last release"? That is, if I build from `stable-4.6.x`, I want a snapshot build to be prefixed `4.6.1.1-0` or `4.6.2-0` while if I build from `master`, I'd want `4.6.99` (`.99` is used as it assumes it is before `4.7.0` but reasonably after any bugfix release of `4.6.x` series) or `4.7.0-0`. I see three ways of doing this: 1. Have Jenkins produce RPMs as build artifacts. Keep the "next release version" information for each branch in the Jenkins build. This builds on your idea of allowing `./makesrpm.sh` take the base version as a CLI argument. So, the knowledge is stored outside the repository: people would have to go to Jenkins to get the RPMs or make reasonable guesses when they are building. 2. Tag `master` immediately after forking a stable branch (such as `4.7.x.branch`? Something...). So, the release knowledge would be stored inside git -- but it's a bit opaque. This is the _closest_ option to what is done today. 3. Actually store a "version number" somewhere in the repository. This makes the next target very visible - but runs the chance of the tag and contents of the repository running out of sync. *However*, this is something Travis-CI can catch! There's no clear "winner" of the three to me. Do you see an obvious route? Maybe a fourth option? -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/xrootd/xrootd/pull/521#issuecomment-305182238 ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the XROOTD-DEV list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1