17 Nov
2014
17 Nov
'14
10 a.m.
On Sat, Nov 15, 2014 at 2:43 PM, Clemens Klein-Robbenhaar
<c.robbenhaar(a)espresto.com> 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… ;)
[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.
Clemens
--
Thomas Mortagne
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/t…
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
devs(a)xwiki.org
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
robbenhaar(a)espresto.com
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 