[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? Nir
+1 On Wed, Jun 1, 2016 at 12:51 PM, Nir Soffer <nsoffer@redhat.com> 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?
Nir _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
----- 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
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)
On Wed, Jun 1, 2016 at 1:21 PM, Eyal Edri <eedri@redhat.com> wrote:
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
+1
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)
On 01/06/16 13:51 +0300, Nir Soffer 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?
+1 -- Adam Litke
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. Martin On Wed, Jun 1, 2016 at 12:51 PM, Nir Soffer <nsoffer@redhat.com> 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?
Nir _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
On Wed, Jun 1, 2016 at 4:19 PM, Martin Sivak <msivak@redhat.com> 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@redhat.com> 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?
Nir _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
On Wed, Jun 1, 2016 at 4:21 PM, Nir Soffer <nsoffer@redhat.com> wrote:
On Wed, Jun 1, 2016 at 4:19 PM, Martin Sivak <msivak@redhat.com> 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@redhat.com> 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?
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@redhat.com> wrote:
On Wed, Jun 1, 2016 at 4:19 PM, Martin Sivak <msivak@redhat.com> 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@redhat.com> 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.
On Sun, Jun 5, 2016 at 9:25 AM, Dan Kenigsberg <danken@redhat.com> wrote:
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@redhat.com> wrote:
On Wed, Jun 1, 2016 at 4:19 PM, Martin Sivak <msivak@redhat.com> 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@redhat.com> 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.
I think we can keep the current way we set the version, but replace the serial number with a timestamp. Nir
participants (9)
-
Adam Litke -
Barak Korren -
Dan Kenigsberg -
Eyal Edri -
Francesco Romani -
Martin Perina -
Martin Sivak -
Nir Soffer -
Piotr Kliczewski