<div dir="ltr">Hi Jay,<div><br></div><div>No problem. I just wanted to know if other vendors/maintainers shared the same problems</div><div>and concerns we have and if we could have an uniform solutions across all drivers which</div><div>is not the case.</div><div><br></div><div>Erlon</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em sáb, 29 de jun de 2019 às 15:19, Jay S. Bryant <<a href="mailto:jungleboyj@gmail.com">jungleboyj@gmail.com</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Erlon,<br>
<br>
I appreciate the goal here but I agree with Gorka here.<br>
<br>
The drivers are the vendor's responsibilities and they version them as <br>
they wish.  I think updating the devref some best practices <br>
recommendations would be good and maybe come to agreement between the <br>
cores on what the best practices are so that we can try to enforce it to <br>
some extent through reviews.  That is probably the best way forward.<br>
<br>
Jay<br>
<br>
On 6/28/2019 2:50 AM, Gorka Eguileor wrote:<br>
> On 27/06, Erlon Cruz wrote:<br>
>> Hey folks,<br>
>><br>
>> Driver versions has being a source of a lot of confusions with costumers.<br>
>> Most of our drivers<br>
>> have a version number and history that are updated as the developers adds<br>
>> new fixes and<br>
>> features. Drivers also have a VERSION variable in the version class that<br>
>> should be bumped by<br>
>> developers. The problem with that is:<br>
>><br>
>>     - sometimes folks from the community just push patches on drivers, and<br>
>> its hard to bump<br>
>>       every vendor version correctly;<br>
>>     - that relies in the human factor to remember adding it, and usually<br>
>> that fails;<br>
>>     - if we create a bugfix and bump the version, the backport to older<br>
>> branches will carry the<br>
>>       version, which will not reflect the correct driver code;<br>
>><br>
>> So, the solution I'm proposing for this is that we use the Cinder<br>
>> versions[1] and remove all<br>
>> version strings for drivers. Every new release we get a version. For stable<br>
>> versions, from time to<br>
>> time the PTL bumps the stable version and we have an accurate ways to<br>
>> describe the code.<br>
>> If we need to backport and send something to the costumer, we can do the<br>
>> backport, poke<br>
>> the PTL, and he will generate another version which can be downloaded on<br>
>> github or via PIP,<br>
>> and present the version to our costumers.<br>
>><br>
>> So, what are your thought around this? Anyone else has had problems with<br>
>> that? What would<br>
>> be the implications of removing the driver version strings?<br>
>><br>
>> Erlon<br>
>><br>
> Hi Erlon,<br>
><br>
> I am personally against removing the drivers versions, as I find them<br>
> convenient and think they are good practice.<br>
><br>
> A possible solution for the driver versioning is for a driver to<br>
> designate a minor version per OpenStack release and use the patch<br>
> version to track changes.  This way one can always backport a patch and<br>
> will just need to increase the patch version in the backport patch.<br>
><br>
> Maybe we can have this formally described in our devref.   We tell<br>
> driver developers they can do whatever they want with the versioning in<br>
> master, but backports must not backport the version as it is and instead<br>
> increase the patch version.<br>
><br>
> What do you think?<br>
><br>
> If I remember correctly there are some drivers that only increase the<br>
> version once per release.<br>
><br>
> Cheers,<br>
> Gorka.<br>
><br>
>> [1] <a href="https://releases.openstack.org/teams/cinder.html" rel="noreferrer" target="_blank">https://releases.openstack.org/teams/cinder.html</a><br>
>> [2]<br>
>> <a href="https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/solidfire.py#L237" rel="noreferrer" target="_blank">https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/solidfire.py#L237</a><br>
<br>
</blockquote></div>