Hi Ernesto, We are fully aware of this! That's why the migration guide is split into "API breaks" and "Behavior changes". API breaks usually are easy to fix because the compiler complains about them. Behavior changes are not problem for Semantic Versioning but we postpone them to major versions because of what you have said below - they are silent and more hard to be debugged. For all of them there is a respective discussion thread at dev@ - whether, when and how to do them. I know that most people are busy with their own business and family (me included!) and don't have time to participate in discussions, brainstorming, testing but this process is the best we can do at the moment. Any ideas for improving the process are always welcome!
I hope that we will release 8.0.0-M1 soon so more people like you can give it a try and report issues and ideas for improvements before we freeze the code for API breaks. Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Tue, May 10, 2016 at 9:32 AM, Ernesto Reinaldo Barreiro < [email protected]> wrote: > Tobias, > > > > I think as long as the third party library is not Wicket 7.0 proofed you > > should use it careful. Because of this the migration guide is very > useful - > > each framework should be checked when upgrade a major version. > > > > > Mind that I'm fully aware of the personal sacrifices some people make to > deliver new versions and improve the framework. So, what I tell bellow is > with full respect to that. > > I'm NOT really "complaining" let's say I'm just voicing some concerns from > users. This is the second Wicket application I migrate to Wicket 7.0 in > last two of months. First application was for a customer and we encountered > a few little "surprises", e.g. > > > https://cwiki.apache.org/confluence/display/WICKET/Migration+to+Wicket+7.0#MigrationtoWicket7.0-org.apache.wicket.markup.html.panel.FeedbackPanelDonotsetCSSclassontheli > >spanelementforafeedbackmessageWICKET-4831 > > IMHO changes like this bring no real value and just make migrations less > "stable". Not to mention things like this > > > https://ci.apache.org/projects/wicket/guide/7.x/guide/componentQueueing.html > > which might have made framework slower (according to certain post on > list). I know that without changes there is no evolution. I'm just telling > that maybe there is a need to make changes more gradually (e.g. deprecate > things) and try to introduce features (if possible) in a way that they can > be "switched off". > > Even on OS level there is a requirement note and sometimes API changes have > > impact on applications and their complete compatibility. > > > > IMHO users just expect things to work out of the box. More if they are just > very satisfied with the version of the product they are using and the only > reason they are actually migrating is just to not "fall behind". There was > already something called Wicket 2.0 which was abandoned after a few months > of development because, if I remember correctly, it broke too much previous > version code base. As a user I would like not to experience something > similar anymore. I haven't tried yet Wicket 8.x but I'm a bit afraid it > might be a bit disruptive for some users/applications. I will want to try > it ASAP and give my modest feedback. > > > -- > Regards - Ernesto Reinaldo Barreiro >
