28 Mar
2012
28 Mar
'12
9:31 p.m.
On Mar 28, 2012, at 9:12 PM, Denis Gervalle wrote:
On Wed, Mar 28, 2012 at 20:03, Vincent Massol
<vincent(a)massol.net> wrote:
Yes. What you say is not fully true from my POV (and from what I've heard from other
users). I've myself installed XARs that were developed in XE 1.1 and they worked
mostly without any issue. The only issue I've found were with skin elements (like the
search icon, etc) but at the api level all my apps were still working fine.
Also, the move from 3.1 to 3.4 is not a valid example. We have made a lot of regression
during this time especially with hibernate and we've fixed those so someone moving
from 3.1 to 3.5.1 or 4.0 will not have the same problems.
On Mar 28, 2012, at 7:10 PM, Denis Gervalle wrote:
The reason I proposed 4 is because nowadays there still are quite a few
XWiki 1.x instances in the wild so if people have coded apps on 1.x and
then upgrade to 4.0 (for ex) it would be nice if their app still works.
However I think it's ok to not support apis done in 0.9. And next year it
would be ok to drop 1.x api support, etc.
It's long but then we can see in the wild that it's important we provide
stable scripting apis for users since they're used a lot while java apis
are used by more savvy user (developers) and thus having a shorter removing
cycle for them (1 year) should be ok.
What would you like to propose instead?
At the same time, many feature as probably evolved since 1.x and may still
render your application not workable AS IS in 4.x. Think about the skin,
even if theorically albatross should still work, I am sure there is many
unexpected issue with it, and using it in 4.x would probably not give you
much advantage over your 1.x setup... My last experience between 3.1 and
3.4 has already issues. I would understand keeping compatibility so long if
you do not introduce alternative, but in most case we do. I do not imagine
a user of 1.x that really expect moving to 4.x without some effort, and
without expecting some improvement other than a better core system. So, are
we really targeting real use case ? On Wed, Mar 28, 2012 at 12:27, Vincent Massol
<vincent(a)massol.net>
wrote:
> Hi devs,
>
> I'd like to change our deprecation strategy. Here's what we are
currently
> supposed to use (we voted it a long time
ago):
>
>
http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HDepreca…
>
> "
> In addition our rule is to keep @deprecated methods/classes for 2 final
> releases after the version where they were first added has been
released as
> final.
> For example if a method is deprecated in, say XE 1.3M2 then the method
> will be removed in 1.6M1 or after. Of course any major new release can
> deprecate anything. For example a XWiki 2.0 release is allowed to break
> backward compatibility (obviously we need to be careful to offer a
> migration path for users of previous major versions).
> "
>
> Issues:
> * This seems a bit harsh to me for some of our users/devs in the
community.
> * We're not following which proves to me
it's not a good rule
> * It doesn't say anything about Scripting APIs which require a greater
> stability in order not to break all wiki pages
>
> Definition of a Scripting API:
> * a Script Service (that's the new way of providing script apis)
> * a class in the "api" package in xwiki-platform-oldcore (this is the
old
> way of providing script apis)
>
> Thus I'd like to propose this new rule:
>
> * Deprecated methods can only be removed in the next Release Cycle. For
> example something deprecated in version N.x can be removed in version
N+1.y
> where x and y can be anything. This is
logical since N+1 means a new
major
> release and it's common to understand
that major releases have no
guarantee
> of API compatibility (See
http://en.wikipedia.org/wiki/Software_versioningfor example).
* For
scripting APIs we can remove deprecated API only after 4 Release
Cycles. For example since we're in 4.x this means we
Why four ? isn't it too much ? Keeping compatibility is a huge effort in maintenance
and may also slow
down evolution, and I just found having a so long compatibility field, to
be too much compare to our team.
Yes but you're forgetting that we're not an application. We're a development
platform which is the same as saying that we're a language. And a language needs
stability. You can compare to other dev languages you know and check how frequently they
break apis in general...
Also, having different policies for java
and scripting is also a complexity, both in term of development and
understanding.
Sure but that's not the reality. The vast majority of XWiki users who develop on XWiki
are developing in wiki pages. There's only a very small minority that code in java and
use the java non-scripting apis.
So I would be in favor to have a single policy for
all.
What Thomas propose seems really reasonable IMO, deprecating preferably in
N+2.0. This is not a obligation anyway, and on a case by case basis we may
still derogate to the rules, if a specific feature seems important to keep.
There is no obligation for user to migrate, and with a clear deprecation
documentation in the release notes, it should be quite easy to maintain old
scripts.
WDYT ?
While it's nice to have the same deprecation strategy both types of API it'll
never work. This means that we're allowed to remove now (in 4.0) apis that have been
deprecated in 1.x and 2.x.
Since the vast majority of XE installs in the wild are using XE 2.x they'll all have a
lot of work to do when they upgrade to 4.x (since they'll make the jump from 2.x to
4.x).
I have the strong feeling that people using XE in production (like Ludovic) would not like
this very much…
Let's get more feedback from other committers.
Thanks
-Vincent
PS: I'd personally be more than happy to remove deprecation as soon as possible but I
also understand that we have to be kind to our users.
> Thanks
> -Vincent
>
>>> can remove deprecated APIs from 0.x releases. And when we start 5.x we
>>> will be able to remove deprecated scripting apis deprecated in 1.x.
>>>
>>> Here's my +1
>>>
>>> Thanks
>>> -Vincent