The aim wasn't to be focused on what's easiest for Horizon at all; it was a
suggestion to let plugins keep moving during brief periods of instability when
people make mistakes. We're aware of the plugins need for stability and correct
deprecation, but we won't catch everything.
That said, there
I think basing the plugins against master is the best solution since
the plugin in development will want to work with the matching horizon
release. Finding issues sooner and hopefully one at a time is a lot
easier to address than a bundle of them at the end of a release cycle.
Hopefully, Horizon do
Kirill: The failures are just as visible, since the cores still control merging
anyway. The only difference is that if it takes a few days to fix something in
upstream Horizon, you needn't block your own content in the meantime. Later in
the release cycle (around N-3, for example) cores could ju
On 20/07/2016 15:13, Rob Cresswell wrote:
> Yes, it would mean changing your requirements after a release. So, for
> example you might run two gate tests:
>
> - A voting Horizon-stable/milestone test, (or both)
> - A non-voting Horizon-master test
>
> That gives you a lot of control over making you
Initially I don’t think I like the idea of making master-horizon job non-voting
for murano-dashboard.
Here are some reasons:
1) We would still need to fix murano-dashboard to work with master
horizon (since we would need to be released together)
2) The breakage would be less vis
Yes, it would mean changing your requirements after a release. So, for example
you might run two gate tests:
- A voting Horizon-stable/milestone test, (or both)
- A non-voting Horizon-master test
That gives you a lot of control over making your tests passing (multiple
patches to make the Horizo
On 20/07/2016 10:16, Rob Cresswell wrote:
> Hey all,
>
> So we've had a few issues with plugin stability recently, and its
> apparent that many plugins are building off Horizon master as a
> dependency. I would really advise against this. A more manageable
> development process may be to:
>
> - Bas
Hi,
testing against stable release of horizon doesn't have any sense of me.
when you have tests running against master and them are almost always
passing it's much easier to found commit that caused a failure and fix the
problem that it's introduced. anyway, it's great news that FF is moved a
week
Hey all,
So we've had a few issues with plugin stability recently, and its apparent that
many plugins are building off Horizon master as a dependency. I would really
advise against this. A more manageable development process may be to:
- Base stable plugins against a stable release of Horizon
-
