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@redhat.com> wrote:

----- Original Message -----
> From: "Nir Soffer" <nsoffer@redhat.com>
> To: "devel" <devel@ovirt.org>, "Dan Kenigsberg" <danken@redhat.com>, "Francesco Romani" <fromani@redhat.com>, "Piotr
> Kliczewski" <pkliczew@redhat.com>, "Adam Litke" <alitke@redhat.com>, "Yaniv Bronheim" <ybronhei@redhat.com>, "Sandro
> Bonazzola" <sbonazzo@redhat.com>
> 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@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)