Hi Ed, Hi Alexander,
Thank you for raising your concerns.
TLDR: EMF Forms is not deprecated, it is in maintenance mode as indicated on the project website. Being on the release train is far more than a couple of minutes of work if we want to do it right. EMF Forms is very stable in terms of API usage and there have been no compatibility issues for many years. We therefore do not foresee any impact on adopters when leaving the train. However, we want to leave the release train early enough, not in a rush when there is actually a real issue somewhere in the future.
Longer answer:
The issue is that it is actually not a few minutes if you want to do it right. Being on the release train also means to ensure its quality from my POV. Maybe a difference to other projects is that we have UI contributions. As an example, the UI components of the EMF Forms tooling are not looking good on the dark theme that was introduced. This is not a real issue for any existing user or adopters, but for people who look at the release train or more precisely the EPP, this looks unpolished. We need to spend significant resources on maintaining the release train contribution, particularly on testing. This is not about a few minutes.
We actually waited pretty long before taking this step and maintained the contribution for over a decade. We want to be more proactive with maintaining our contribution and not harm the general quality of the train.
We don't expect typical users and adopters to be negatively impacted by the decision to leave the release train. There has not been any breakage with new Eclipse versions in projects we know about in EMF Forms since many many years. This means use cases in existing projects typically work well and are not impacted. If there are any issues, there still are channels to contact the community and us, in order to fix potential issues and to produce new releases. But this is then based on request, when it really is needed. We expect to test and fix compatibility for known projects typically once per year. However, we do not want to generically promise compatibility for every new version and unknown projects without extensive testing and without knowing there is a specific need by an adopter.
I hope with this explanation, the decision makes more sense. Alexander, we are of course happy for any contributions and or comments!
Best regards,
Jonas