<div dir="ltr">Hi Doug,<div><br></div><div>We discussed this option a bit too. Maybe we need to think about this again.</div><div><br></div><div>From my point of view, it would be better to keep current release model for now, </div>because we've got a very small amount of active horizon contributors, so current release<div>model helps us deliver the project in time. From the other side, your option is less</div><div>complicated and could be easier to implement. </div><div><br></div><div>Let's get more feedback from the team before further discussion.</div><div><br></div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Regards,<br>Ivan Kolodyazhny,<br><a href="http://blog.e0ne.info/" target="_blank">http://blog.e0ne.info/</a></div></div></div></div>
<br><div class="gmail_quote">On Wed, Jun 13, 2018 at 6:43 PM, Doug Hellmann <span dir="ltr"><<a href="mailto:doug@doughellmann.com" target="_blank">doug@doughellmann.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Excerpts from Ivan Kolodyazhny's message of 2018-06-13 18:01:26 +0300:<br>
<div><div class="h5">> Hi team,<br>
> <br>
> Last week on the Horizon meeting we discussed [1] possible options for<br>
> Horizon release model to address current issues for plugins maintainers.<br>
> Some background could be found here [2].<br>
> <br>
> The main issue is that we should have some stable API for plugins and be<br>
> able to release it as needed. We're trying to cover several use cases with<br>
> this effort. E.g:<br>
> - do not break plugins with Horizon changes (cross-project CI would help<br>
> with some issues here too)<br>
> - provide an easy way to develop plugins which require specific Horizon<br>
> version and features<br>
> <br>
> For now, most of the plugins use 'horizon' package to implement<br>
> dashboard extensions. Some plugins use parts of 'openstack_dashboard'<br>
> package. In such case, it becomes complicated to develop plugins based on<br>
> current master and have CI up and running.<br>
> <br>
> The idea is to introduce something like 'horizonlib' or 'horizon-sdk' with<br>
> a stable API for plugin development. We're going to collect everything<br>
> needed for this library, so plugins developers could consume only it and do<br>
> not relate on any internal Horizon things.<br>
> <br>
> We'd got horizonlib in the past. Unfortunately, we missed information about<br>
> what was good or bad but we'll do our best to succeed in this.<br>
> <br>
> <br>
> If you have any comments or questions, please do not hesitate to drop few<br>
> words into this conversation or ping me in IRC. We're going to collect as<br>
> much feedback as we can before we'll discuss it in details during the next<br>
> PTG.<br>
> <br>
> <br>
> [1]<br>
> <a href="http://eavesdrop.openstack.org/meetings/horizon/2018/horizon.2018-06-06-15.01.log.html#l-29" rel="noreferrer" target="_blank">http://eavesdrop.openstack.<wbr>org/meetings/horizon/2018/<wbr>horizon.2018-06-06-15.01.log.<wbr>html#l-29</a><br>
> [2]<br>
> <a href="http://lists.openstack.org/pipermail/openstack-dev/2018-March/128310.html" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/2018-<wbr>March/128310.html</a><br>
> <br>
> Regards,<br>
> Ivan Kolodyazhny,<br>
> <a href="http://blog.e0ne.info/" rel="noreferrer" target="_blank">http://blog.e0ne.info/</a><br>
<br>
</div></div>Another solution that may end up being less work is to release Horizon<br>
using the cycle-with-intermediary model and publish the releases to<br>
PyPI. Those two changes would let you release changes at any point in<br>
the cycle, to support your plugin authors, and would not require<br>
reorganizing the code in Horizon to build a new release artifact.<br>
<br>
The release team would be happy to offer advice about how to make the<br>
changes, if you want to talk about it.<br>
<br>
Doug<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</blockquote></div><br></div>