<moving discussing to dev> I'm not against API breaks, just make them count, especially when you are changing stuff people actually use. If things get nasty trying to support the old API, just leave it. For the example I gave (AbstractValidator), supporting the old API is a no-brainer.
IMHO people that don't read warnings should not be writing code at all. The warning is there to warn you about something (hence the name). If you do not fix deprecation warnings, you will have trouble with the next upgrade, but that's your own choice. Emond On Thursday 02 February 2012 01:22:11 Eelco Hillenius wrote: > Heh. You're opening your email arguing to get the breaks over with, > but then cheer for putting them off again :-) > > I prefer to break hard (compile errors) and get it over with for major > releases, even if you can deprecate instead. These deprecated methods > just pollute your API, people often don't read the warnings or don't > care about them, and sometimes stuff can get nasty trying to support > both new ways and keep old ways around. > > Just my 2c of course, > > Eelco > > > On Thu, Feb 2, 2012 at 12:54 AM, Emond Papegaaij > > <[email protected]> wrote: > > I agree, so +1. Also, a postponed API break still is an API break. Our > > users have to fix this sooner or later. IMHO the discussion about API > > break is more that we should try to avoid API breaks when possible, but > > if it's not possible to fix an important issue without breaking the API, > > go ahead and break the API. > > > > One more thing I like to point out is that fixing a deprecation warning > > often is much easier than fixing a compiler error. If you want to change > > or remove methods/classes, please leave the old version in there marked > > @Deprecated if possible. This gives you a very good place to document the > > migration steps (in addition to the migration guide) and even an example > > how to work with the new API. > > > > For example, the changes that were made in the validation code (removal of > > AbstractValidator), gave me quite some problems migrating our codebase. If > > AbstractValidator would not have been removed, but marked @Deprecated and > > reimplemented using the new API, migration would have been much easier. > > > > Best regards, > > Emond > > > > On Thursday 02 February 2012 09:33:11 Sven Meier wrote: > >> This is stuff I'll gladly accept API breaks for. > >> > >> +1 > >> > >> Sven > >> > >> Am 02.02.2012 05:00, schrieb Igor Vaynberg: > >> > WICKET-499 and WICKET-2705 have been outstanding for a good while. i > >> > have fixed them, but at the cost of some API breaks. in the light of > >> > the previous discussion on API breaks here is your chance to -1 this > >> > before i take the time to polish and document it in the migration > >> > guide. > >> > > >> > http://git-wip-us.apache.org/repos/asf/wicket.git/commitdiff/sandbox/fe > >> > edb > >> > ack..master?p=wicket.git;a=commitdiff;h=sandbox/feedback;hp=master > >> > > >> > -igor
