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?) 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
