Github user aledsage commented on a diff in the pull request:
https://github.com/apache/brooklyn-server/pull/810#discussion_r140603081
--- Diff:
rest/rest-api/src/main/java/org/apache/brooklyn/rest/api/CatalogApi.java ---
@@ -153,6 +153,9 @@ public Response createFromUpload(
@QueryParam("forceUpdate") @DefaultValue("false")
boolean forceUpdate);
+ /** @deprecated since 0.13.0 delete the bundle via DELETE
/catalog/bundles/xxx */
+ // but we will probably keep this around for a while as many places
use it
+ @Deprecated
--- End diff --
I'm still uncomfortable about the way we're handling our versioning, and
with deprecating `/v1/catalog` methods. To me, the old `/catalog` is the "v1
way of doing it". Once we do a properly versioned `/v2` then it will be clear
that v1 is deprecated (and we'll document it as such).
But we can go with this for now.
For future work, it would be great if we can get a process in place by
which we version the api in a sensible way: to help people understand what they
are using, what is replacing it, and how/when it will be deprecated.
A big problem with `@Deprecated` here is that I don't think an api user is
told about it at all (it's not even in the swagger), so from the perspective of
a rest-api-user it's as though it's not deprecated.
---
