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.