On Thu, Oct 27, 2016 at 10:11 AM, Loic Dachary <loic@xxxxxxxxxxx> wrote: > > > On 27/10/2016 17:04, Abhishek Varshney wrote: >> If I understand the concerns right, how about doing it the other way round? > > That would make a lot of sense. It would however require changing the scripts that are used for the release and I suspect it won't be possible for the same reasons changing them to use the SHA1 did not happen. Right, I think we would need to alter the build workflow to avoid hard-coding any version at all within /debian/changelog, so that we no longer need to do the "bump" commit, similar to what we do for the RPMs with ceph.spec.in. In Jenkins/Gitbuilder, we already have Jenkins run "dch" on every build, to further distinguish trusty vs xenial builds that would otherwise have the same NVR. I think we'd need to expand that concept to also get the entire version from "git describe". It would be cool to have this work so we could tag/release arbitrary SHA1s on jewel, rather than having to bump /debian/changelog on the tip of the branch and then tag that "new version" bump commit. - Ken -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
