29 Mar
2012
29 Mar
'12
11:14 a.m.
On Wed, Mar 28, 2012 at 11:28 PM, Caleb James DeLisle
<calebdelisle(a)lavabit.com> wrote:
On 03/28/2012 02:03 PM, Vincent Massol wrote:
This is actually not expected and should be fixed, the current rule is
not never use anything coming from legacy packages. It's technically
enforced at java level but it's harder at wiki page level.
On Mar 28, 2012, at 7:10 PM, Denis Gervalle wrote:
I'd rather we had no hard rules lest dogmatic adherence to the rules becomes an
excuse not to fulfill our obligation to do what's best for the software.
I'm not exactly sure what `break' means since there's no reason I can see for
these functions to be removed from the compatibility aspect.
I propose:
#1 Move remaining deprecated scripting API methods from oldcore into legacy-oldcore
compatibility aspect.
That means these:
http://nexus.xwiki.org/nexus/service/local/repositories/releases/archive/or…
#2 Get xwiki-enterprise building and testing with xwiki-platform-oldcore instead of
xwiki-platform-legacy-oldcore.
Add an xwiki-enterprise-legacy-jetty-hsql build profile so that we can test in parallel,
with and without legacy-oldcore.
I ran the UI tests and it appears that we have a few dependencies on legacy-oldcore. IMO
this is very bad. However it doesn't look like we have too many.
Lets get it running, see the failing tests, report the issues, then fix them. On Wed, Mar 28, 2012 at 12:27, Vincent Massol
<vincent(a)massol.net> 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? 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 ?
#3 Stop shipping legacy-oldcore by default. Users can always swap platform-oldcore for it
on their own.
#4 Aggressively move deprecated internal (non-script api) code into the compatibility
aspect, this will allow us to simplify the oldcore, and potentially even remove
dependencies.
If we want to stall, we can stall at #3, having 1, 2, and some of 4 taken care of will
make the final decision the flip of a switch.
Caleb
--
Thomas Mortagne
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs > 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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs