Quarkus: Add metadata to mark an extension as deprecated on code.quarkus.io

[ppalaga]

We'd like to deprecate camel-quarkus-hystrix extension, because the underlying Camel component got deprecated by Camel https://camel.apache.org/components/latest/eips/hystrix-eip.html Once Camel removes the component, we (Camel Quarkus) will be forced to remove it as well. The users are advised to use MP Fault Tolerance instead.

Implementation ideas

AFAIK, the status field currently supports stable, preview and experimental. I am not 100% sure deprecated should be added there. I'd say it is perfectly reasonable for an extension to be stable and deprecated at the same time.

Except for the logical deprecation status, it would be nice to be able to express also

• Since which version the extension is deprecated, e.g. `deprecatedSince: "Camel Quarkus 1.2.3"
• A free text field for the reason for the deprecation and/or any possible replacements

[emmanuelbernard]

/CC @ia3andy @maxandersen

So status is really our only visual queue of the status of an extension. the idea was not to overwhelm people with 2 or more "types" of status they don't necessarily see or understand the implications of (despite greater accuracy). But we can think of amending it if needed. I would personally favor a simple single field if we can.
A deprecation text field would be useful to guide people indeed but I'd like to see where we would make use of it and expose it to the user before going for it.

When you mention Camel Quarkus 1.2.3, I think it means a thing for a Camel user using Quarkus underneath, I wonder what it means of a Quarkus platform user using this camel extension.

[ppalaga]

When you mention Camel Quarkus 1.2.3, I think it means a thing for a Camel user using Quarkus underneath, I wonder what it means of a Quarkus platform user using this camel extension.

I admit the Quarkus platform version number would be more useful there (and also in general, because we do not use quarkus-extension.yaml anywhere else), but the problem is that quarkus-extension.yaml is maintained on the Camel Quarkus level where we cannot tell upfront which Platform version will the given Camel Quarkus release be part of.

[emmanuelbernard]

you sort of do know that if you want to deprecate extension Foo ad day D, then the closest release of Quarkus platform after day D will be the one. But to your point, it feels like deprecation is a platform stuff more than an extension stuff.

[ppalaga]

you sort of do know that if you want to deprecate extension Foo ad day D, then the closest release of Quarkus platform after day D will be the one.

Not exactly. We have to release Camel Quarkus between D and Quarkus platform release. It already happened in the past, that we have not caught the train. Releasing at ASF has some procedural overhead. But it perhaps does not matter so much if we are sometimes not 100% accurate with the deprecation version estimate.

But to your point, it feels like deprecation is a platform stuff more than an extension stuff.

Not sure I follow. Could you please explain that? We definitely need to maintain the deprecation metadata on our side too (probably as runtime POM's properties) because we want to expose them on the extension pages, like e.g. on the Hystrix extension page https://camel.apache.org/camel-quarkus/latest/extensions/hystrix.html

[ia3andy]

Sorry I've been struggling with something else, let me get up to date with this :)

[ia3andy]

Ok, let me know if I have to do something on code.quarkus.io to support a new tag in status, or anything else..

[emmanuelbernard]

Ok, let me know if I have to do something on code.quarkus.io to support a new tag in status, or anything else..

That's why I added you in so you can figure out the UX, UI and internal mechanism consequences of such an extra flag.

[ppalaga]

So far, the minimal working proposal is to support deprecated as a new value of status.

If there is no consensus about deprecatedSince and deprecationNote, I can try to pack that info into description.

[ia3andy]

just as a note, code.quarkus.io supports having multiple tags in the "status". Here is how it looks like on code.quarkus.redhat.com:

[emmanuelbernard]

you sort of do know that if you want to deprecate extension Foo ad day D, then the closest release of Quarkus platform after day D will be the one.

Not exactly. We have to release Camel Quarkus between D and Quarkus platform release. It already happened in the past, that we have not caught the train. Releasing at ASF has some procedural overhead. But it perhaps does not matter so much if we are sometimes not 100% accurate with the deprecation version estimate.

But to your point, it feels like deprecation is a platform stuff more than an extension stuff.

Not sure I follow. Could you please explain that? We definitely need to maintain the deprecation metadata on our side too (probably as runtime POM's properties) because we want to expose them on the extension pages, like e.g. on the Hystrix extension page https://camel.apache.org/camel-quarkus/latest/extensions/hystrix.html

So imagine that there are two platforms, one is the Quarkus Community and another is Red Hat Build of Quarkus. Maybe the community deprecates Histrix while the Red Hat deprecates it say a few months later.
I think we have the way to externalize the overriding of that information per platform but I wanted to point out that the deprecation is really a platform choice (driven by the extension of course).

[ia3andy]

If there is no consensus about deprecatedSince and deprecationNote, I can try to pack that info into description.

@ppalaga I think the description is fine and more flexible, I could even tell the user (in the "deprecated" tooltip) to have a look at the description to get more info about the deprecation.

[ppalaga]

code.quarkus.io supports having multiple tags in the "status"

What is the type of the value then?

A comma separated string?

status: "stable,deprecated"

Or yaml list?

status: 
  - "stable"
  - "deprecated"

[ia3andy]

@ppalaga you can use both, but the second is nicer IMO.