28 Jan
2016
28 Jan
'16
5:49 p.m.
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 (guillaume.delhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
28 Jan
28 Jan
5:59 p.m.
New subject: [xwiki-devs] [Proposal] Support retro-compatibility for page objects
On Thu, Jan 28, 2016 at 5: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.
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 (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
--
Thomas Mortagne
6 p.m.
New subject: [xwiki-devs] [Proposal] Support retro-compatibility for page objects
+1 by the way
On Thu, Jan 28, 2016 at 5:59 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
On Thu, Jan 28, 2016 at 5:49 PM, Guillaume Delhumeau
<guillaume.delhumeau(a)xwiki.com> wrote:
--
Thomas Mortagne
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 (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
--
Thomas Mortagne 
29 Jan
29 Jan
7:45 a.m.
New subject: [xwiki-devs] [Proposal] Support retro-compatibility for page objects
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
9:26 a.m.
New subject: [xwiki-devs] [Proposal] Support retro-compatibility for page objects
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
<mariusdumitru.florea(a)xwiki.com> wrote:
On Thu, Jan 28, 2016 at 6:49 PM, Guillaume Delhumeau
<
guillaume.delhumeau(a)xwiki.com> wrote:
--
Thomas Mortagne
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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
9:28 a.m.
New subject: [xwiki-devs] [Proposal] Support retro-compatibility for page objects
On Fri, Jan 29, 2016 at 10:26 AM, Thomas Mortagne <thomas.mortagne(a)xwiki.com
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
> <mariusdumitru.florea(a)xwiki.com
wrote:
> > 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
> >>
> > _______________________________________________
> > devs mailing list
> > devs(a)xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
>
>
>
> --
> Thomas Mortagne
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
3206
days inactive
3207
days old
5 comments
3 participants
participants (3)
-
Guillaume Delhumeau -
Marius Dumitru Florea -
Thomas Mortagne