@bbockelm : My bad, I thought you are using some random git hash for the devel branches, but you are actually using the right one prefixed with a 'g' as in git describe.
Two questions:
-
Why do you need the SHA1 hash in the RPM release?
-
Why would we need the 4.6.99 ?
NOTE: when master is pointing at a new release series, we should then
tag something along the lines of the next release. For example, once
master is pointing at 4.7.x, we should make a tag of 4.6.99.
Regarding the branching and tagging, we have a stable branch per 'minor' release (e.g. stable-4.6.x), both RC and release tags go to the stable branches. And I think that's it.
(I will be merging the stable branches back to master starting with the next release, it seems to me like a reasonable thing to do).
In general I'm not against your idea, I think we just need to iron out the details ;-)
Would the following schema work for you:
xrootd-4.6.1-1.master.91.c41d4c13
This is very intuitive: it's 4.6.1-1 + 91 commits from branch master, the last one of them being c41d4c13.
I would skip both the 'g' and 'git' as we are using only git anyway. I think we can leave out the 'pre' interfix, as it carries no additional info.
(Also, it would be awesome, if we could have a switch that allows to replace the 91 with a value chosen by the user.)
4.6.1-1 < 4.6.1-1.master.91.gc41d4c1 && 4.6.1-2 > 4.6.1-1.master.91.c41d4c13
which is what we want, right?
Let me know your thoughts!
—
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":"@simonmichal in #521: @bbockelm : My bad, I thought you are using some random git hash for the devel branches, but you are actually using the right one prefixed with a 'g' as in git describe. \r\n\r\nTwo questions:\r\n\r\n1. Why do you need the SHA1 hash in the RPM release?\r\n\r\n2. Why would we need the 4.6.99 ?\r\n\u003e NOTE: when master is pointing at a new release series, we should then\r\n\u003e tag something along the lines of the next release. For example, once\r\n\u003e master is pointing at 4.7.x, we should make a tag of 4.6.99.\r\n\r\n\r\nRegarding the branching and tagging, we have a stable branch per 'minor' release (e.g. stable-4.6.x), both RC and release tags go to the stable branches. And I think that's it. \r\n(I will be merging the stable branches back to master starting with the next release, it seems to me like a reasonable thing to do).\r\n\r\nIn general I'm not against your idea, I think we just need to iron out the details ;-)\r\n\r\nWould the following schema work for you:\r\nxrootd-4.6.1-1.master.91.c41d4c13\r\n\r\nThis is very intuitive: it's 4.6.1-1 + 91 commits from branch master, the last one of them being c41d4c13.\r\n\r\nI would skip both the 'g' and 'git' as we are using only git anyway. I think we can leave out the 'pre' interfix, as it carries no additional info.\r\n(Also, it would be awesome, if we could have a switch that allows to replace the 91 with a value chosen by the user.)\r\n\r\n4.6.1-1 \u003c 4.6.1-1.master.91.gc41d4c1 \u0026\u0026 4.6.1-2 \u003e 4.6.1-1.master.91.c41d4c13\r\nwhich is what we want, right?\r\n\r\nLet me know your thoughts!"}],"action":{"name":"View Pull Request","url":"https://github.com/xrootd/xrootd/pull/521#issuecomment-305176543"}}}
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