On May 23, 2012, at 1:25 PM, Caleb James DeLisle wrote: > 3 -1's so there is definitely plenty of agreement in this case. > > My understanding is that in "Distribute without legacy modules by default" > "distribute" means "distribute [enterprise and manager]", which would make > this a reversal of > the agreement voted upon here: > http://lists.xwiki.org/pipermail/devs/2012-April/050386.html > > At any rate I am curious as to whether the community wants to ever remove > anything. If we want to > get to the point of removing things then I want to help, if we don't want to > then I will accept it.
- We vote to never remove/break things (except on rare occasions) - However we've also decided to not stink by moving things to Legacy and using aspects ;) - Now the next step is to decide how we make users aware of deprecated stuff (removing from the distribution is one way, there are plenty of other ways - warnings in XE when using a deprecated API - Deprecated API Center, flag dependencies using deprecated code, etc). We just need someone to propose something that can work in an acceptable manner. > The way I see it, breaking API and removing code is like taking out the > garbage. When you do it, > you stink and nobody is your friend. If you don't do it, everything stinks > but it does so a little > at a time. It seems to work reasonably well.. Oracle, Sun and Microsoft have > been doing it for years. Not true, Sun/Oracle have not done that for Java. They've always kept backward compat. and taken that seriously. I don't know too much about Microsoft but I can't imagine any development platform breaking users without offering an upgrade path. > All I care about is that we have a plan, if we want to remove stuff then lets > make it happen, if we > want to never remove anything then lets make it a conscious decision. I don't > like the idea of having > the decision make itself while we put it off. We all agree we need to find a solution. To summarize, ATM, we all agree about the general strategy, we just haven't found an acceptable implementation yet :) Thanks -Vincent > Caleb > > > > On 05/23/2012 06:09 AM, Paul Libbrecht wrote: >> Could they be shipped but deactivated by default? >> And let the EM activate them? Sounds normal for an EM job though I agree >> it's an extra work. >> Making it visible is a good way to encourage the people to upgrade their >> extensions or make them "visible is old grumps". >> >> paul >> >> >> Le 23 mai 2012 à 10:34, Thomas Mortagne a écrit : >> >>> -1 too, not bundling at least core extensions legacy modules will make >>> EM more or less unusable for many extension older than the current >>> version right now. >>> >>> On Wed, May 23, 2012 at 9:43 AM, Marius Dumitru Florea >>> <[email protected]> wrote: >>>> On Tue, May 22, 2012 at 5:58 PM, Vincent Massol <[email protected]> wrote: >>>>> Hi Caleb, >>>>> >>>>> On May 22, 2012, at 5:00 PM, Caleb James DeLisle wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I understand we agreed in >>>>>> http://lists.xwiki.org/pipermail/devs/2012-March/050172.html to stop >>>>>> bundling legacy modules by default. What was not so clear is how we >>>>>> should do this. >>>>>> >>>>>> I want to remove the modules from XE and Manager, and document the >>>>>> method of downloading them from >>>>>> maven.xwiki.org and replacing the existing .jar files with them. >>>>> >>>>> It's not enough IMO. Here's a likely scenario: >>>>> >>>>> * Users will download the version without legacy modules. >>>>> * Then they'll use the Extension Manager to install extensions from >>>>> extensions.xwiki.org >>>>> * The extensions will fail >>>>> * Users will ditch xwiki since it just doesn't work and the quality is >>>>> perceived as not good enough. >>>>> >>>>> We need to solve this before we can stop bundling the legacy modules IMO. >>>>> >>>>>> Why: >>>>>> >>>>>> #1. Not removing API is obviously unsustainable in the long term. >>>>>> >>>>>> #2. Replacing core .jar files has been judged to be beyond the scope of >>>>>> the extension manager. >>>>>> Whether we want to support overriding classes using extensions as a >>>>>> "function hooking" mechanism is a possible topic for future discussion. >>>>>> >>>>>> #3. Replacing .jar files in the .war is not an excessively complex task, >>>>>> we ask users to open the >>>>>> war file for configuring a database or adding JDBC connectors, cases >>>>>> where there is much less >>>>>> technical need to require opening the .war file. >>>>>> >>>>>> >>>>>> Here's my +1 to remove it ASAP, for 4.1M2 if we can get the tests >>>>>> passing. >>>>> >>>> >>>>> -1 till we solve the question above. I'd rather keep legacy modules than >>>>> have dissatisfied users. >>>> >>>> -1 for the same reason. >>>> >>>> Thanks, >>>> Marius >>>> >>>>> >>>>> Thanks >>>>> -Vincent >>>>> >>>>>> >>>>>> Caleb _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
