On Thu, Jan 28, 2016 at 6:49 PM, Guillaume Delhumeau < [email protected]> wrote:
Hello.
In XWiki, we take care of retro-compatibility. Each class that is not internal is considered as API, and we have clirr to detect when an API breakage is done.
However, we don't apply this strategy regarding the page objects of our functional tests. I noticed this when I've tried to use some pages objects defined on an application based on platform 6.4.1 on an other application based on platform 7.4. Due to incompatibility issues, I had to rewrite some page objects in my new application.
It will be a major issue when we will move some current core extensions to contrib.
So I propose considered Page Objects as API, and to add CLIRR checks on the build.
This won't fully fix your problem because Page Objects developers will use the @Unstable annotation http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#H40Unstab... that can stay for a full cycle. Once we move an extension out of platform to contrib it will have its own release cycle, which can be longer or less than a year depending on how actively it is maintained. We have extensions in platform that are rarely being modified during a release cycle. I understand the problem but I feel it would be a burden to maintain backwards compatibility for page objects (go through @Unstable, @Deprecated and then legacy). If you check the existing page objects you'll see that they are not always very well thought or consistent, at least not as good as the actual APIs that are being tested. Thanks, Marius
WDYT?
Thanks, -- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs