> On 10 Mar 2016, at 07:46, Richard Jones <[email protected]> wrote: > > It has been mentioned, xstatic packages can block the gate. We currently > control xstatic package releases, thus we can roll back, if something > goes wrong. > > If we're pulling directly with npm/bower, someone from the outside can > break us. We already have the situation with pypi packages. > With proper packages, we could even use the gate to release those > packages and thus verify, we're not breaking anyone. > > We're going to have potential breakage (gate breakage, in the integrated > tests) any time we release a package (regardless of release mechanism) and > have to update two separate repositories resulting in out-of-sync version > specification and expectation (ie. upper-constraints specification and > Horizon's code expectation) as described in my OP. The only solution that > we're aware of is to synchronise updating those two things, through one of > the mechanisms proposed so far (or possibly through a mechanism not yet > proposed.)
If we will anyway have potential breakage I don’t understand why the better solution here would not be to just use the bower and npm tools which are standardised for JavaScript and would move Horizon more towards using widely recognised tooling from within not just Openstack but the wider development community. Back versions always need to be supported for a time, however I would add that long term this could end up saving time and create a stable longer term solution. > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
