On Wed, Mar 4, 2015 at 9:13 AM, Emond Papegaaij <emond.papega...@topicus.nl> wrote:
> On Tuesday 03 March 2015 21:23:37 Martin Grigorov wrote: > > On Tue, Mar 3, 2015 at 9:11 PM, Emond Papegaaij < > emond.papega...@topicus.nl> > > wrote: > > > I don't like keeping code around just for the sake of keeping it > around. > > > Even unmaintained code takes time to maintain. For example, the code > needs > > > to be updated for Wicket 7 to keep it compiling, this will happen again > > > with Wicket 8 etc. It might also need changes to migrate to newer > servlet > > > api's, Java versions, etc. What will happen with deprecation warnings > that > > > are introduced when dependencies get updated? All this takes time we > could > > > also spend on other things. > > > > What you say is correct but it will be even more work if everyone has to > > either migrate his/her *working* code to the new Tree impl or to copy the > > classes from 6.x and maintain them locally. > > That's always the trade off you have to make. At our company, we have used > a > special deprecated code module in the past. This module contained code that > was working fine, but you were no longer suppose to use. This worked quite > well for us. > > > WicketStuff InMethodGrid is currently excluded from the build in 7.x > > because it uses the old Tree and for 2 years no one spend his time to fix > > the deprecation warnings and migrate it to the new Tree impl... > > So are we going to re-introduce it now the code stays available? :) > Yes. InMethod Grid is used by many applications. Most of its users probably do not even know it uses deprecated APIs. One way is to leave it disabled and force the community to migrate it. Another way is to copy the old Tree classes in InMethod Grid project and use them locally. The third way is to introduce a project for the old Tree, with deprecated classes and documentation explaining that it is not maintained. > > Best regards, > Emond > >
