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
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: