You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
flare-plugins is meant to take over for the legacy flare-operations-plugins and flare-publishing-plugins projects. As of now, all functionality has been moved over, with the exclusion of the docker-related build/clean tasks and supporting DSL for defining containers.
Currently, StarChart-Labs does not distribute any projects via docker - early prototypes for things like Chronicler were dockerized, but eventually transformed into different deployment models. As such, there is nowhere within the organization where the docker plug-ins are used in a practical sense, which increases the risk to consumers of these plug-ins (as we don't have anywhere we would notice practical use problems with the implementation)
This leaves us with a couple choices:
Re-implement the plug-ins here, and rely on external consumers to notice and file issues
Drop support for these plug-ins, and find an open-source plug-in set to recommend as a replacement for migrating users
Drop support for these plug-ins, without an officially endorsed replacement
The text was updated successfully, but these errors were encountered:
Personally, I would avoid the third option - we should provide at least some guidance to anyone would chose to utilize our libraries, should we choose to drop support for this functionality
flare-plugins is meant to take over for the legacy flare-operations-plugins and flare-publishing-plugins projects. As of now, all functionality has been moved over, with the exclusion of the docker-related build/clean tasks and supporting DSL for defining containers.
Currently, StarChart-Labs does not distribute any projects via docker - early prototypes for things like Chronicler were dockerized, but eventually transformed into different deployment models. As such, there is nowhere within the organization where the docker plug-ins are used in a practical sense, which increases the risk to consumers of these plug-ins (as we don't have anywhere we would notice practical use problems with the implementation)
This leaves us with a couple choices:
The text was updated successfully, but these errors were encountered: