Replies: 1 comment 1 reply
-
I think this is fine for a temporary solution. As we know, Milo uses an evergreen delivery approach. This makes fixed releases a bit redundant. Long term, Milo will not be the exception for who OST supports and we should move away from fixed releases. With this, I also think we should abandon the React Spectrum UI in favor of something that is more performant and has a more consistent UX with the rest of Milo. At present, OST has certain UX paradigms that can be improved... navlist is currently used as a progress indicator (not what it should be used for), user journey flows inconsistently (left to right, then right to left). It would be good to address all of this as OST moves into Milo Library. |
Beta Was this translation helpful? Give feedback.
-
OST is going to receive multiple updates with respect to flex promo, draft offers, milo specific features and each release of OST will require a consumption PR on the milo side.
Considering the relatively large size of the build(~612kb), I don't think merging those files in the main milo branch is a good thing as it will inflate the repo size unnecessarily.
Therefore I propose to follow the CaaS approach and deploy OST to special pages at https://www.adobe.com/special/tacocat/ost/
Thus, milo could consume always the latest OST version, or a specific version if we decide to support multiple OST versions.
The same could also be imagined for the tacocat library but we can discuss it in another thread.
Beta Was this translation helpful? Give feedback.
All reactions