[ovirt-devel] [URGENT][ACTION REQUIRED] vdsm versioning system need to be fixed

[Yaniv Bronheim]

No. the jobs alright. ovirt-3.6 build each night will output vdsm 4.17.19.
older version than the build for ovirt-3.6.3 which will raise (currently
4.17.23). That's all we wanted, no ? once 3.6.3 will end, ovirt-3.6 new tag
will be the newer version for users that want it

On Tue, Mar 8, 2016 at 10:30 AM, Sandro Bonazzola <sbonazzo at redhat.com>
wrote:

>
>
> On Tue, Mar 8, 2016 at 9:07 AM, Yaniv Bronheim <ybronhei at redhat.com>
> wrote:
>
>> its reasonable that you can't upgrade 4.17.23 to 4.17.19 and it shouldn't
>> be that way.. latest (which afaiu means latest snapshot? ovirt-3.6.3)
>> should get higher numbering than last stable (which should be last tag on
>> ovirt-3.6 branch). in other words, tags in ovirt-3.6.3 must be newer than
>> tags in ovirt-3.6 branch until we stop to update ovirt-3.6.3 and backport
>> only to ovirt-3.6 - than we can continue to tag ovirt-3.6. bottom line, as
>> I see it - as long as ovirt-3.6.3 alive we raise the tagging only there
>>
>>
> this breaks automation at several layers.
> are you saying that we shouldn't put in ovirt-master-snapshot what comes
> out from ovirt-3.6 branch but push there only the output of 3.6.3 branch?
> If so, at least 3 new jenkins jobs (check patch, check merge, build
> artifact) have to be created and the nightly publisher need to be updated.
> Who's maintaining VDSM jenkins jobs?
>
>
>
>
>>
>>
>> On Mon, Mar 7, 2016 at 6:39 PM, Sandro Bonazzola <sbonazzo at redhat.com>
>> wrote:
>>
>>>
>>>
>>> On Mon, Mar 7, 2016 at 1:29 PM, Yaniv Bronheim <ybronhei at redhat.com>
>>> wrote:
>>>
>>>> Again, I should understand the direction you ack here ... and its not
>>>> clear in any way I try to read it
>>>> lets summaries current status:
>>>> master == v4.17.999 (I recalled 4.18 tag for 4.0... probably it hasn't
>>>> happened yet)
>>>> ovit-3.6.3 last commit points to v4.17.23 (and also contains in its
>>>> history 4.17.22 4.17.21 4.17.20 and 4.17.19
>>>> ovirt-3.6 == was not tagged since v4.17.19
>>>>
>>>> So, as far as I see - last "official published" version is tagged
>>>> anyway. once we'll finish with z-streams, we can continue tagging only on
>>>> ovirt-3.6 branch. but as long as we publish new snapshots (or z-stream
>>>> releases as I call them) we can continue the tagging only on ovirt-3.6.3
>>>> branch
>>>>
>>>> The rest of your suggestions can't help in any way. if you prefer you
>>>> can use 4th level versioning (4.17.x-y) later on. but currently we just
>>>> continue to raise the current 4.17 we have
>>>>
>>>> now, getting back to the origin mail that Sandro sent:
>>>>
>>>> """ snip
>>>> > vdsm-4.17.19-32.git171584b.el7.centos.src.rpm
>>>> <http://jenkins.ovirt.org/job/vdsm_3.6_build-artifacts-el7-x86_64/178/artifact/exported-artifacts/vdsm-4.17.19-32.git171584b.el7.centos.src.rpm> because
>>>> the last tag on the 3.6 branch was 4.17.19 and new tags have been created
>>>> in different branches.
>>>>
>>>> this is correct - no problem with that approach, new tag still will be
>>>> higher then 4.17.19 as we see with 4.17.23
>>>>
>>>> > This make impossible to upgrade from stable (4.17.23) to latest
>>>> snapshot.
>>>>
>>>> But we just said that stable (ovirt-3.6) is 4.17.19 and latest is
>>>> 4.17.23 - so it sounds right to me.
>>>>
>>>
>>>
>>> No, we said that stable is 4.17.23 and latest is 4.17.19. So we can't
>>> upgrade from stable to latest, since latest has lower version than stable.
>>>
>>> Let's make it simple, try install stable and then try to upgrade to
>>> snapshot.
>>>
>>> You'll see yourself.
>>>
>>>
>>>
>>>
>>>>
>>>> > This also break dependencies on other projects requiring the latest
>>>> released version like hosted engine.
>>>>
>>>> No its not. HE may require 4.17.23 which is the latest we publish as
>>>> part of 3.6.3
>>>>
>>>> """
>>>>
>>>> Yaniv Bronhaim.
>>>>
>>>> On Mon, Mar 7, 2016 at 1:58 PM, Dan Kenigsberg <danken at redhat.com>
>>>> wrote:
>>>>
>>>>> On Mon, Mar 07, 2016 at 12:06:32PM +0200, Nir Soffer wrote:
>>>>> > +1
>>>>> >
>>>>> > On Mon, Mar 7, 2016 at 10:29 AM, Sandro Bonazzola <
>>>>> sbonazzo at redhat.com> wrote:
>>>>> > >
>>>>> > >
>>>>> > > On Mon, Mar 7, 2016 at 9:03 AM, Martin Perina <mperina at redhat.com>
>>>>> wrote:
>>>>> > >>
>>>>> > >>
>>>>> > >>
>>>>> > >> ----- Original Message -----
>>>>> > >> > From: "Yaniv Bronheim" <ybronhei at redhat.com>
>>>>> > >> > To: "Martin Perina" <mperina at redhat.com>
>>>>> > >> > Cc: "Nir Soffer" <nsoffer at redhat.com>, "Sandro Bonazzola"
>>>>> > >> > <sbonazzo at redhat.com>, "Francesco Romani"
>>>>> > >> > <fromani at redhat.com>, "Dan Kenigsberg" <danken at redhat.com>,
>>>>> "devel"
>>>>> > >> > <devel at ovirt.org>
>>>>> > >> > Sent: Monday, March 7, 2016 8:16:05 AM
>>>>> > >> > Subject: Re: [ovirt-devel] [URGENT][ACTION REQUIRED] vdsm
>>>>> versioning
>>>>> > >> > system need to be fixed
>>>>> > >> >
>>>>> > >> > I don't understand what's the different .. that's what we
>>>>> currently do.
>>>>> > >> > Sandro complains that he can't upgrade latest stable which can
>>>>> be
>>>>> > >> > 4.17.23
>>>>> > >> > to latest snapshot which can be 4.17.19.88 \ 4.17.19-88 - yum
>>>>> can't
>>>>> > >> > consider that as an upgrade and 4.17.19.88 can't fill HE
>>>>> requirement for
>>>>> > >> > 4.17.23
>>>>> > >>
>>>>> > >> oVirt 3.6 stable release:
>>>>> > >>   - current [1]: vdsm-4.17.23-0.el7.centos.noarch.rpm
>>>>> > >>   - desired:     vdsm-4.17.23-1.el7.centos.noarch.rpm
>>>>> > >>
>>>>> > >> oVirt 3.6 stable snapshot:
>>>>> > >>   - current [2]: vdsm-4.17.19-32.git171584b.el7.centos.noarch.rpm
>>>>> > >>   - desired:     vdsm-4.17.24-0.1.git171584b.el7.centos.noarch.rpm
>>>>> > >>
>>>>> > >> oVirt master snapshot:
>>>>> > >>   - current [3]:
>>>>> vdsm-4.17.999-680.gitd87d031.el7.centos.noarch.rpm
>>>>> > >>   - desired:
>>>>>  vdsm-4.18.0-0.680.gitd87d031.el7.centos.noarch.rpm or
>>>>> > >>                  vdsm-5.0.0-0.680.gitd87d031.el7.centos.noarch.rpm
>>>>> > >>     (not sure what will be oVirt 4 vdsm version)
>>>>> > >>
>>>>> > >
>>>>> > >
>>>>> > > +1
>>>>>
>>>>> the down side of that is that we'd need to forsake our ability to
>>>>> release a new version by a mere `git tag`, and would have to include a
>>>>> version bump commit instead.
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> *Yaniv Bronhaim.*
>>>>
>>>
>>>
>>>
>>> --
>>> Sandro Bonazzola
>>> Better technology. Faster innovation. Powered by community collaboration.
>>> See how it works at redhat.com
>>>
>>
>>
>>
>> --
>> *Yaniv Bronhaim.*
>>
>
>
>
> --
> Sandro Bonazzola
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.com
>



-- 
*Yaniv Bronhaim.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20160308/43c0dcf9/attachment-0001.html>