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:
- 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.
- 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.
- 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, view it on GitHub, or mute the thread.
{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/xrootd/xrootd","title":"xrootd/xrootd","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/xrootd/xrootd"}},"updates":{"snippets":[{"icon":"PERSON","message":"@bbockelm in #521: 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.\r\n\r\nSomething 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`.\r\n\r\nWhat about `4.6.1.1-0.master.91.gc41d4c1`? That meets the criteria of RPM versioning and keeps the release number prefixed with 0.\r\n\r\nWe still have the problem of determining the \"last release\". `git describe` gets confused because we don't merge stable branches through master.\r\n\r\nPerhaps 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`.\r\n\r\nI see three ways of doing this:\r\n1. 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.\r\n2. 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.\r\n3. 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!\r\n\r\nThere's no clear \"winner\" of the three to me. Do you see an obvious route? Maybe a fourth option?"}],"action":{"name":"View Pull Request","url":"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
