29 Jan
2016
29 Jan
'16
7:45 a.m.
On Thu, Jan 28, 2016 at 6:49 PM, Guillaume Delhumeau <
guillaume.delhumeau(a)xwiki.com> 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#H40Unsta…
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 (guillaume.delhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs