On Sun, Jun 5, 2016 at 9:25 AM, Dan Kenigsberg <[email protected]> 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 <[email protected]> wrote: >> > On Wed, Jun 1, 2016 at 4:19 PM, Martin Sivak <[email protected]> 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 <[email protected]> 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 _______________________________________________ Devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/devel
