1) deprecate *every* version that is not likely to get an important
issue (even if it only concerns a core plugin) fixed timely - no matter
how old it is. Anything else is lying to yourself and your users about
your capability. There is no shame in not beeing able to support a
version after the next one was released given that this support is not
beeing paid for.
2) think about (and communicate) support cycles before you introduce
breaking changes. Only provide *one *LTS-Version if you feel you can
handle that commitment.
4) try to support usecases rather than plugins - if something old needs
to be droped you can provide a new solution instead of dragging old
stuff with you
5) try and do contnuous delivery. If you can not because of the way that
plugins are kept apart from maven try at least to introduce regular
releasetrains with small changesets. maybe eclipse could step in and
help with that ?
I believe all this would help users and developers to deal with changes
in a more professional way. This could also free up time to introduce
new concepts and features that are long overdue.
Debeka Krankenversicherungsverein a. G.
Debeka Lebensversicherungsverein a. G.
Debeka Allgemeine Versicherung AG
Debeka Pensionskasse AG
Debeka Bausparkasse AG
Abteilung IT-Grundlagen & -Engineering
IT-Prozesse und Automatisierung (IE/P)