[xwiki-devs] [Proposal] Support retro-compatibility for page objects
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. WDYT? Thanks, -- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project
On Thu, Jan 28, 2016 at 5: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.
Not only Page Object themself since the issue you have here is with TestUtils but the whole Page Object related framework.
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
-- Thomas Mortagne
+1 by the way On Thu, Jan 28, 2016 at 5:59 PM, Thomas Mortagne <[email protected]> wrote:
On Thu, Jan 28, 2016 at 5: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.
Not only Page Object themself since the issue you have here is with TestUtils but the whole Page Object related framework.
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
-- Thomas Mortagne
-- Thomas Mortagne
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
IMO the main issue (and the issue Guillaume really had even if he talked about page objects) is not at all with the page object of the application but with test framework, TestUtils being the flagship. So IMO we should take better care of retro compatibility in TestUtils and its friends. Contribution page object is each contrib project policy anyway. On Fri, Jan 29, 2016 at 7:45 AM, Marius Dumitru Florea <[email protected]> wrote:
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
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Fri, Jan 29, 2016 at 10:26 AM, Thomas Mortagne <[email protected]
wrote:
IMO the main issue (and the issue Guillaume really had even if he talked about page objects) is not at all with the page object of the application but with test framework, TestUtils being the flagship.
So IMO we should take better care of retro compatibility in TestUtils and its friends. Contribution page object is each contrib project policy anyway.
I'm ok with this.
On Fri, Jan 29, 2016 at 7:45 AM, Marius Dumitru Florea <[email protected]> wrote:
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
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (3)
-
Guillaume Delhumeau -
Marius Dumitru Florea -
Thomas Mortagne