oscerd commented on issue #2890:
URL:
https://github.com/apache/camel-kamelets/issues/2890#issuecomment-5522183790
Refreshing this against Camel **4.22.0**, since the audit behind it was done
at 4.21 and the decision should be made on current data.
## Nothing has moved
All three components are still deprecated, and still present — none has been
removed upstream:
| component | deprecated in 4.22.0 | since | non-deprecated sibling |
|---|---|---|---|
| `json-patch` | **yes** | 3.12.0 | none |
| `paho` | **yes** | 2.16.0 | `paho-mqtt5` (not deprecated) |
| `splunk` | **yes** | 2.13.0 | `splunk-hec` (not deprecated) |
So the issue's conclusion still holds: no action is forced, and the three
options are unchanged. Worth noting `paho` has been deprecated since 2.16.0 and
`splunk` since 2.13.0 — both have sat deprecated for many major versions
without removal, which is mild evidence that option 3 (wait for upstream
removal) is not as risky as it might sound.
## One gap worth separating from the decision
Whatever is decided about migration, users currently get **no signal at
all**. All five affected Kamelets are marked `Stable`:
```
mqtt-source support="Stable"
mqtt-sink support="Stable"
splunk-sink support="Stable"
splunk-source support="Stable"
json-patch-action support="Stable"
```
and the catalog has **no deprecation convention** — no Kamelet anywhere
carries a deprecation annotation, and `kamelet.support.level` only ever takes
`Stable` or `Preview`. So there is no existing mechanism to say "this works,
but its component is on the way out", short of wording it into the description.
That is a real gap independent of which option you pick: even option 3 (wait
for upstream) benefits from users knowing before the removal lands rather than
at upgrade time.
## What I have not done
I have not implemented any of the three options. Option 1 needs a convention
that does not exist yet — inventing a `Deprecated` support level or a
`camel.apache.org/kamelet.deprecated` annotation is a catalog-wide contract
change, and tooling reads these annotations, so it is not something to
introduce inside a follow-up issue. Option 2 changes protocol behaviour for
`mqtt-*` users and needs the upgrade-guide note the issue already calls for.
If it would help, I can open a separate issue proposing a deprecation marker
convention for the catalog — that is the piece which unblocks option 1 and is
useful regardless of what is decided here. Say the word and I will write it up.
---
_Claude Code on behalf of Andrea Cosentino_
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
