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
As part of implementing the RFC for catalogd's content storage and serving mechanism we are moving away from serving catalog contents via CustomResources. We should deprecate all feature gates related to serving catalog contents via CustomResources and ensure that the default method of serving the catalog contents is the HTTP server.
The text was updated successfully, but these errors were encountered:
Do we need to deprecate? We're in alpha, I think we can just remove whatever we want (and tell clients when to bump whenever we're ready to get bumped for consumers)
This is a fair point. I was making an assumption that it would be better to deprecate based on the fact that we added feature gates for the API change from Package + BundleMetadata to CatalogMetadata CRs but if we would prefer to just remove this functionality all together that's fine by me.
I think it's okay to remove when we're ready without a deprecation window.
Regardless, we should introduce the new functionality before deprecating or removing the old functionality. And we probably shouldn't remove the old functionality until:
Other known consumers (e.g. operator-controller) have been updated to support the new functionality.
The experience of a user browsing the catalog contents is reasonably on-par with the old functionality.
As part of implementing the RFC for catalogd's content storage and serving mechanism we are moving away from serving catalog contents via CustomResources. We should deprecate all feature gates related to serving catalog contents via CustomResources and ensure that the default method of serving the catalog contents is the HTTP server.
The text was updated successfully, but these errors were encountered: