From: "Nir Soffer" <nsoffer(a)redhat.com&gt; To: "devel" <devel(a)ovirt.org&gt;, "Dan Kenigsberg" <danken(a)redhat.com&gt;, "Francesco Romani" <fromani(a)redhat.com&gt;, "Piotr Kliczewski" <pkliczew(a)redhat.com&gt;, "Adam Litke" <alitke(a)redhat.com&gt;, "Yaniv Bronheim" <ybronhei(a)redhat.com&gt;, "Sandro Bonazzola" <sbonazzo(a)redhat.com&gt; Sent: Wednesday, June 1, 2016 12:51:49 PM Subject: [VDSM] New versioning scheme Hi all, We are going to branch 4.0 today, and it is a good time to update our versioning scheme. I suggest to use the standard ovirt versioning, use by most projects: 1. master vdsm-4.19.0-201606011345.gitxxxyyy 2. 4.0 vdsm-4.18.1 The important invariant is that any build from master is considered newer compare with the stable builds, since master always contain all stable code, and new code. Second invariant, the most recent build from master is always newer compared with any other master build - the timestamp enforces this. Thoughts?

adding infra also, in case we need to do changes in ci/builds. On Wed, Jun 1, 2016 at 1:58 PM, Francesco Romani <fromani(a)redhat.com&gt; wrote: > ----- Original Message ----- > > From: "Nir Soffer" <nsoffer(a)redhat.com&gt; > > To: "devel" <devel(a)ovirt.org&gt;, "Dan Kenigsberg" <danken(a)redhat.com&gt;, > "Francesco Romani" <fromani(a)redhat.com&gt;, "Piotr > > Kliczewski" <pkliczew(a)redhat.com&gt;, "Adam Litke" <alitke(a)redhat.com&gt;, > "Yaniv Bronheim" <ybronhei(a)redhat.com&gt;, "Sandro > > Bonazzola" <sbonazzo(a)redhat.com&gt; > > Sent: Wednesday, June 1, 2016 12:51:49 PM > > Subject: [VDSM] New versioning scheme > > > > Hi all, > > > > We are going to branch 4.0 today, and it is a good time to update our > > versioning scheme. > > > > I suggest to use the standard ovirt versioning, use by most projects: > > > > 1. master > > > > vdsm-4.19.0-201606011345.gitxxxyyy > > > > 2. 4.0 > > > > vdsm-4.18.1 > > > > The important invariant is that any build from master is considered > newer > > compare with the stable builds, since master always contain all stable > > code, and new code. > > > > Second invariant, the most recent build from master is always newer > compared > > with any other master build - the timestamp enforces this. > > > > Thoughts? > > +1 > > given how Vdsm build system works, it should be a matter of just pushing > the 4.19.0 tag against master after the branch > >

Bests, > > -- > 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 > > > -- Eyal Edri Associate Manager RHEV DevOps EMEA ENG Virtualization R&D Red Hat Israel phone: +972-9-7692018 irc: eedri (on #tlv #rhev-dev #rhev-integ)

1. master vdsm-4.19.0-201606011345.gitxxxyyy

1. master vdsm-4.19.0-201606011345.gitxxxyyy

On Wed, Jun 1, 2016 at 4:19 PM, Martin Sivak <msivak(a)redhat.com&gt; wrote: >> 1. master >> >> vdsm-4.19.0-201606011345.gitxxxyyy > > Ack and +1 to the idea, but I have one small comment. Isn't it usual > in Fedora (for example) to use the following? > > vdsm-4.19.0-0.201606011345.gitxxxyyy > > Please note the zero in the release part (-0.something). The stable is > then released as vdsm-4.19.0-1 keeping the version intact. Thanks for correcting me Martin, I omitted the release number mistake. > > Martin > > On Wed, Jun 1, 2016 at 12:51 PM, Nir Soffer <nsoffer(a)redhat.com&gt; wrote: >> Hi all, >> >> We are going to branch 4.0 today, and it is a good time to update our >> versioning scheme. >> >> I suggest to use the standard ovirt versioning, use by most projects: >> >> 1. master >> >> vdsm-4.19.0-201606011345.gitxxxyyy >> >> 2. 4.0 >> >> vdsm-4.18.1 >> >> The important invariant is that any build from master is considered newer >> compare with the stable builds, since master always contain all stable >> code, and new code. >> >> Second invariant, the most recent build from master is always newer compared >> with any other master build - the timestamp enforces this. >> >> Thoughts?

On Sat, Jun 04, 2016 at 04:17:32PM +0300, Nir Soffer wrote: > On Wed, Jun 1, 2016 at 4:21 PM, Nir Soffer <nsoffer(a)redhat.com&gt; wrote: > > On Wed, Jun 1, 2016 at 4:19 PM, Martin Sivak <msivak(a)redhat.com&gt; wrote: > >>> 1. master > >>> > >>> vdsm-4.19.0-201606011345.gitxxxyyy > >> > >> Ack and +1 to the idea, but I have one small comment. Isn't it usual > >> in Fedora (for example) to use the following? > >> > >> vdsm-4.19.0-0.201606011345.gitxxxyyy > >> > >> Please note the zero in the release part (-0.something). The stable is > >> then released as vdsm-4.19.0-1 keeping the version intact. > > > > Thanks for correcting me Martin, I omitted the release number mistake. > > > >> > >> Martin > >> > >> On Wed, Jun 1, 2016 at 12:51 PM, Nir Soffer <nsoffer(a)redhat.com&gt; wrote: > >>> Hi all, > >>> > >>> We are going to branch 4.0 today, and it is a good time to update our > >>> versioning scheme. > >>> > >>> I suggest to use the standard ovirt versioning, use by most projects: > >>> > >>> 1. master > >>> > >>> vdsm-4.19.0-201606011345.gitxxxyyy > >>> > >>> 2. 4.0 > >>> > >>> vdsm-4.18.1 > >>> > >>> The important invariant is that any build from master is considered newer > >>> compare with the stable builds, since master always contain all stable > >>> code, and new code. > >>> > >>> Second invariant, the most recent build from master is always newer compared > >>> with any other master build - the timestamp enforces this. > >>> > >>> Thoughts? > > Dan? Yes, it's a good idea. I'd appreciate if it is implemented in such a way that there is no need for an explicit commit to introduce a new version. Currently it's done by a mere `git tag`. But that's not a hard requirement. Feel free to have a "bump version" commit like most other projects out there.