We are well aware that people are developing commercial applications and have deadlines to meet. In fact we have those ourselves. I think both Martin's projects and our company's are probably in the top 10 or top 5 of biggest Wicket applications out there. We have to do this work too, with managers and customers.
That is why we don't break API compatibility on a whim, we do it to improve things. Rather than silently have things be broken, we make breakages as explicit as possible. Would you actually fix anything if we mark things deprecated? Will you actively scan your application logs for warnings? And your co-workers? And all the ten thousand developers? We have moved to semantic versioning to make live easier for people to upgrade between minor versions and for us to break API-when we consider such breakage an improvement between major versions. It is my preference to maintain a monthly schedule for minor versions and a yearly schedule for major versions. Semantic versioning prevents us from removing deprecated API in minor versions, so when we keep old deprecated API lingering, we have to commit to supporting that for another full major release. With a team of a few developers this is unattainable. Semantic versioning does give us a way to deprecate API's prior to releasing a major version: release a minor version with the deprecations in it. Unfortunately you typically can't act on the deprecations because the new, modified API is not present in the minor release. So there you have catch 22: deprecations in your code you can't act on, and still a breakage when upgrading to a new major version. With Wicket's release process we make life already fairly easy: we support the current and previous release. So you now have almost had over a year to perform the upgrade to 6, while still receiving new versions for 1.5.x. Martijn On Fri, Oct 18, 2013 at 4:09 PM, [email protected] <[email protected]> wrote: > Martin, > > Wicket is a really superb web framework, and we really appreciate all your > hard work in providing this to us. > However we are just providing some constructive feedback to make you aware > that upgrade issues are important to serious users of the framework, and you > have commercial products depending on it. It's a testimony to the quality of > Wicket that it can be used in this way. > Just be aware that we have people breathing down our necks, and deadlines to > meet. So any time spent ironing out code breakages creates questions about > the products we're using. > > Once again, thanks for your work in developing Wicket, you're doing a > fantastic job! > > Andrew > > > > > On 18/10/13 14:48, Martin Grigorov wrote: >> >> Hi, >> >> Thanks! >> >> We expect such kind of feedback when we release Release Candidate >> versions. >> It is a bit late for 6.x but you can help us for Wicket 7.0. >> >> The "good" news is that 7.x won't be released soon because it has no >> enough >> breaking changes. >> The Migration >> guide<https://cwiki.apache.org/confluence/display/WICKET/Migration+to+Wicket+7.0> >> is >> very well documented. Much better than 1.4->1.5 and 1.5->6.0 ones, IMO, >> but >> since it has no big changes which would cause big headaches to you (our >> users) it won't be released until we find some. >> >> There is irony in what I'm saying but this is what I understood the last >> time we discussed the matter. >> >> Now to your points. See inline. >> >> On Fri, Oct 18, 2013 at 3:41 PM, Carolyn Gerrard < >> [email protected]> wrote: >> >>> Hi folks, >>> >>> We have a large web application engineering management system deployed in >>> production environments that is written in Wicket. During the last >>> couple >>> of weeks I have been upgrading to Wicket 6 from Wicket 1.5 in order to >>> use >>> the new nested tree and table-tree components and I have to say these >>> are >>> really good both in terms of the flexibility of display and performance, >>> unlike the former in-method grid component. >>> >>> As a technology Wicket has a lot of advantages but one of the things that >>> constantly concerns us and our management is the amount of effort that >>> has >>> to go into porting to a new release of Wicket. I'd like to ask about >>> your >>> strategy for release upgrades as you need to be aware of the impact on >>> serious users of your product in not supporting backward compatibility of >>> interfaces. >>> >>> For example, with this port to Wicket 6 one of the changes was to the >>> SortableDataProvider. It went from: >>> private class AssignAppModulesDataProvider extends >>> SortableDataProvider<AppModule> { >>> ... >>> @Override >>> public Iterator<AppModule> iterator(int >>> start, int count) { >>> ... >>> } >>> >>> @Override >>> public int size() { >>> return ... ; >>> } >>> } >>> to >>> >>> private class AssignAppModulesDataProvider extends >>> SortableDataProvider<AppModule, String> { >>> ... >>> >>> @Override >>> public Iterator<AppModule> iterator(long >>> start, long count) { >>> ... >>> } >>> >>> @Override >>> public long size() { >>> return ... ; >>> } >>> } >>> >>> As a one off change this may not seem much but we have well over a 100 >>> different instances of SortableDataProviders in our application and >>> furthermore were using start and count variables in the List.subList call >>> which expects int . Surely a better approach would have been to >>> introduce a new class that supported the new interface and deprecate the >>> SortableDataProvider in order to prevent compilation breakage and a >>> staged >>> migration. >>> >> This change causes compilation problems, so it should be easy for the >> developer to fix them, no ? >> Maybe your approach with duplicate interfaces is achievable but this means >> to duplicate all implementations of these interfaces... No one suggested >> it >> when 6.0-SNAPSHOT has been in development so we it wasn't considered. >> >> >>> Another example is the restriction that the AjaxFallbackLink can no >>> longer >>> be associated with html buttons and throws an exception at runtime if you >>> do. We had dozens of examples of this in code, and it was fairly painful >>> tracking them all down as I had to look at both java and html files to >>> identify the ones that came into this category. >>> >> Runtime breaks are worse the compilation breaks, I agree. >> >> It was a bug fix actually. >> AjaxFallbackLink won't fallback if used with a button because <button> has >> no "href" attribute. >> We could have logged a warning instead and leave your application broken >> for another year or two. >> I'm not sure which solution is better. >> >> >>> Also the in-code rendering of js and css resources has changed >>> completely. >>> Whilst I very much like the new interfaces and classes, would it not >>> have >>> been possible to deprecate the existing ones at least for a release. >>> >> Again a change causing compilation error. >> I agree it is time consuming to rework it to the new way but it is easy, >> no >> ? >> >> >>> I understand the desire and the need to clean up the architecture of a >>> framework but retaining backward compatibility at least for an interim >>> for >>> a mature product like Wicket really does need to be considered more >>> carefully or people will move away from using this technology. You don't >>> see technologies like Spring breaking like this. >>> >> I understand why you are frustrated. I had to walk the same steps for my >> applications. But I hope you understand that I am a mortal developer like >> you. The only difference between us is that I've decided to give some of >> my >> free time and knowledge to you and other Wicket users. No one forces me to >> do this. I do it because I like the feeling to help other people just for >> "Thank you". >> >> There are a lot more people (and funds) behind products like Spring. I'm >> very glad that you compare Wicket with Spring. This means we are doing >> (relatively) well! >> >> We will try to revisit the changes we made for Wicket 7 and make it even >> simpler where possible for all Wicket users. >> You are always welcome to give us a hand! The same is valid for Tetsuo and >> everyone else! >> >> >>> Regards >>> >>> Carolyn >>> >> Thank you again! >> > > -- Become a Wicket expert, learn from the best: http://wicketinaction.com
