Hi all, it was recently pointed out that Vdsm 4.18.3 rpms have -0 release number, like in rpmbuild/RPMS/x86_64/vdsm-4.18.3-0.fc23.x86_64.rpm But this is OK only for packages built from master. From stable branch and official releases, we should have something like rpmbuild/RPMS/x86_64/vdsm-4.18.3-1.c2e510e.fc23.x86_64.rpm or perhaps just rpmbuild/RPMS/x86_64/vdsm-4.18.3-1.fc23.x86_64.rpm

To quickly unblock 4.0, I posted https://gerrit.ovirt.org/#/c/59337/ - please consider this a quick fix and review as such To properly address the versioning, I posted my take here https://gerrit.ovirt.org/#/q/topic:new-release This is not marked a draft, yet I posted mostly as discussion material, I'm not confident this is really (or completely) the proper way to go. Please share your thoughts. -- Francesco Romani RedHat Engineering Virtualization R & D Phone: 8261328 IRC: fromani _______________________________________________ Devel mailing list Devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/devel

From: "Rafael Martins" <rmartins(a)redhat.com&gt; To: "Francesco Romani" <fromani(a)redhat.com&gt; Cc: devel(a)ovirt.org Sent: Thursday, June 16, 2016 5:42:54 PM Subject: Re: [ovirt-devel] [vdsm] about package release number ----- Original Message ----- > From: "Francesco Romani" <fromani(a)redhat.com&gt; > To: devel(a)ovirt.org > Sent: Thursday, June 16, 2016 5:24:21 PM > Subject: [ovirt-devel] [vdsm] about package release number > > Hi all, > > it was recently pointed out that Vdsm 4.18.3 rpms have -0 release number, > like in > > rpmbuild/RPMS/x86_64/vdsm-4.18.3-0.fc23.x86_64.rpm > > But this is OK only for packages built from master. From stable branch and > official releases, > we should have something like > > rpmbuild/RPMS/x86_64/vdsm-4.18.3-1.c2e510e.fc23.x86_64.rpm > > or perhaps just > > rpmbuild/RPMS/x86_64/vdsm-4.18.3-1.fc23.x86_64.rpm > > To quickly unblock 4.0, I posted > > https://gerrit.ovirt.org/#/c/59337/ - please consider this a quick fix and > review as such You can just merge this patch (or similar one that enforces revision 1) and another patch reverting the changes afterwards, and think about how to improve versioning automation later. This is similar to what we do for engine version bumps currently, and should not "block" releases.