I was working a bit on resolving deprecations. There I came across code where methods are deprecated in favor of another method.
I started to mark the deprecated methods for removal ( @Deprecated(forRemoval=true) and resolve usages of the method (e.g. PR#374).
But should we just throw away the deprecated methods? For the case that someone uses the deprecated methods we could provide OpenRewrite recipes for the migration recipe? If so, would we just clean up now and open issues to add those recipes and implement the recipes later?
Iād mark them as deprecated and remove in the next major version. Itās essential that every deprecated method has an explanation what to use as a replacement.
1.0.0 is the next major version. We could leave them for now, but we would carry already deprecated methods further with us. It is now the chance to become clean.
Alternatively we could offer migration recipes for removed methods, so that code would be cleaned from using such deprecations for the case that the replacement is clear.
I understand that for compatibility reason the old methods can be kept, but users are anyway forced to perform the migrations once.
To keep the migration from C7 as easy as possible I would keep them. The full compatibility is a treasure (the main one IMO). Once C7 is retired, deprecated methods can be removed.
Iād also prefer focussing on a Camunda ā Operaton migration which is as easy as possible. The migration will be the first contact to Operaton for many developers, and not everybody will / can use the OpenRewrite scripts. If the deprecated methods are part of the public API, we could add EOL dates for them in the documentation, so the people using the engine could prepare accordingly?
What about hiding them behind a feature switch? This could be off per default, so new projects wouldnāt use it. But migrated projects can turn it on, if they have used those methods.
I think this is a easy to document feature and adding a config line like deprecated-methods: true for those who need it, is still an easy migration step.
@paul Iām speaking about Java methods that have been deprecated already in the C7 code. They have been deprecated and should not be used by clients. They are still there because clients might still use that. You canāt hide this behind a feature switch. The methods can be marked with @Deprecated(forRemoval=true) to strongly encourage that they will be removed.
We can leave such methods and add āforRemovalā at methods that have not marked yet.
Users have been warned already for a long time that such deprecated methods must not be used anymore. If they do, they are at risk to take action.
We can either enforce that action by cleaning that up, or carry around these methods until release 2.0.
Iād choose the latter so that the transition from C7 to Operaton is as effortless as possible. But I repeat myself since Iāve expressed that already. Having deprecated methods for a little bit longer isnāt going to hurt much IMO but would have a great benefit.
I think we have an agreement that we leave the deprecated methods for now. I will then continue to clean up our own code from using deprecated methods and mark methods for removal.
I would also say the āburdenā to migrate from C7 to Operaton is already high enough. We should start removing this methods months after EOL of C7, when people got used to use Operaton and we have established an active communication channel to our new users.
I donāt know if this is still an issue, but the migration will be effort with or without replacing deprecated methods.
I would remove them in order to start clean rather than starting with technical debts already.
Iām on your side. The agreement that we have now is that we start with this debt and give Users a chance to not have the need to care about it when migrating to 1.0. It also means that there will be a 2.0 not too far in the future where we clean it up.