On Mon, Nov 17, 2014 at 10:00 AM, Thomas Mortagne <[email protected]> wrote: > On Sat, Nov 15, 2014 at 2:43 PM, Clemens Klein-Robbenhaar > <[email protected]> wrote: >> >> I have to admit that I had not looked much into the new possibilities >> that are offered by the Flamingo skin .... shame on me ;) >> >> However I think that: >> >> - most users who do not update the main XWiki software will not care >> about updating the extensions either >> >> - if users care about a new feature but are not willing to get through >> the work of updating the main XWiki platform, then they still can try >> to clone the extension from github and try to maintain a backward >> compatible >> version, or try to find someone who does it for them ... currently >> I do not see the risk of having a big bag of backports dragging behind >> (but maybe I am very mistaken about that). >> >> - aside of that usually the platform version should always match the version >> with which the extension is developed; i.e. if having 5.0.3 in the pom.xml >> then also develop / test with XE 5.0.3 - if developing with 6.3, then >> maybe better use 6.3 in the pom.xml >> (Hm, do I know someone who does not do that ... ah, wait >> https://github.com/xwiki-contrib/application-mocca-calendar/blob/master/pom.xml >> ;) >> [Actually I have been working there not with a 6.x, but 5.4.5 ... but >> still ...) >> >> I can see exceptions where one uses e.g. the new features >> in a backwards compatible way (i.e. using CSS classes that >> are simply not there in colibri), but still some testing should still be >> done with the "supported" XWiki version. >> (In principle some integration tests should be able to do the checks >> automatically, >> but not many extensions have these tests ...) >> >> - having said that, if in doubt I am in favour of upping the XWiki version >> when new XWiki features allow to improve the extension. >> the main problem might be remembering to actually do it :) >> >> - important bugfixes which should be made available to users lagging behind >> might be done in some bugfixing branch - maybe create the branch "just in >> case" before upping the version number to 6.2/6.3 ? >> >> - personally I still tend to stick to 5.4.x, but then that is just because >> of ... see above, >> I am seriously lagging behind on the new UI features. >> Actually doing so introduced bugs with the newest version ( e.g. >> http://jira.xwiki.org/browse/MOCCACAL-62 ) >> that penalizes users who use the newest XWiki version - not a good idea >> ... so maybe I should move to a newer version, too) >> >> Anyway, keeping the "version gap" small might be the only way to avoid the >> "Fragmentation" issues Eduard seems to hint at, given limited resources. >> > > >> (I still have to check how the extension manager handles this ... e.g. >> assuming someone runs an older XWiki version, does >> it allow to pick an older, still compatible version of some extension, or >> does it show the latest version and informs >> the user to update the XWiki before installing it?) > > Depends what part of Extension Manager you are talking about. The > basic search show you the last version (compatible or not, there is no > test) of the extension and then you can choose to install it or any > previous version you can choose in a list. The Extension Updater > select the higher compatible version.
s/higher/highest/ > > >> >> >> Clemens >> >>> Hi, >>> >>> Since 6.3 roadmap we are working on improving a set of applications from >>> Contrib, read more on >>> http://design.xwiki.org/xwiki/bin/view/Proposal/CollaborativeApplications >>> >>> The purpose of the improvement is to make sure they work on the new skin >>> and also that they have an unitary style. We have some design proposals for >>> Calendar, Forum, Meeting and Task. >>> >>> For example this is how the Task app should look like >>> http://design.xwiki.org/xwiki/bin/download/Proposal/TaskApplicationDesign/tasks-app-add.png >>> >>> Problems: >>> A. We are tempted to use (and already started using in some cases) CSS >>> classes from Bootstrap (Flamingo). Here we can enumerate: grid classes, >>> responsive classes, specific BS classes (buttons, labels, etc.). For some >>> of these classes we have some partial equivalent classes in Colibri (.half, >>> .third, .button, etc.) so even if it will not look perfect in Colibri, the >>> app will be displayed. >>> // Flamingo is available since XWiki 6.2 >>> >>> B. Also the image I've just shown is using some icons. We are tempted to >>> use Icon Themes variables, this way the app will be able to adapt to any >>> given IconTheme. >>> // IconThemes is available since XWiki 6.3 >>> >>> C. The apps we are reviewing are still using '$msg.get' we would like to >>> replace that with the new $services.localization >>> // Localization Macro is available since XWiki 4.3 >>> >>> D. Other deprecated calls, depends on the app. >>> >>> The problem is that some apps now have defined the parent version as 4.1, >>> 4.3, 6.2, etc. and might not be a true statement anymore, and the version >>> needs to be updated. >>> >>> Is it ok for the new redesign applications to use new api and be dependent >>> of newer versions of XWiki? This way we can make sure we are creating great >>> looking apps and using the latest functionality for the new versions of the >>> app. In our case that would be 6.3. >>> >>> The downside of this is that you won't be able to upgrade your apps to this >>> new versions we are improving, without migrating/updating your entire wiki. >>> >>> Should we depend on a smaller version? WDTY? >>> >>> Thanks, >>> Caty >>> _______________________________________________ >>> devs mailing list >>> [email protected] >>> http://lists.xwiki.org/mailman/listinfo/devs >>> >> >> >> >> mit freundlichen Grüßen >> Clemens Klein-Robbenhaar >> >> -- >> Clemens Klein-Robbenhaar >> Software Development >> EsPresto AG >> Breite Str. 30-31 >> 10178 Berlin/Germany >> Tel: +49.(0)30.90 226.763 >> Fax: +49.(0)30.90 226.760 >> [email protected] >> >> HRB 77554 B - Berlin-Charlottenburg >> Vorstand: Maya Biersack, Peter Biersack >> Vorsitzender des Aufsichtsrats: Dipl.-Wirtsch.-Ing. Winfried Weber >> Zertifiziert nach ISO 9001:2008 >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs > > > > -- > Thomas Mortagne -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
