Hi, please let me give you a users perspective:
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.
Regards
Jörg Sesterhenn
--
Jörg Sesterhenn
Referent
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)
56058 Koblenz
Telefon: (02 61) 4 98 – 14 55
Telefax: (02 61) 4 98 – 15 41
E-Mail: joerg.sesterh...@debeka.de
Internet: www.debeka.de
Besuchen Sie uns auch in sozialen Netzwerken.
Unsere Adressen finden Sie hier: www.debeka.de/socialmedia
Pflichtangaben der Debeka-Unternehmen
gemäß § 35a GmbHG / § 80 AktG: www.debeka.de/pflichtangaben
