Re: [ovirt-devel] [VDSM] New versioning scheme

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.