[xwiki-devs] [Apps] What is the minimum XWiki version we should depend on /support for the Apps we are reviewing / redesigning?
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/ta... 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
Also for the apps created with AWM, we did some improvements directly inside platform, and we plan to improve more the AWM, so this means newer versions of platform would be needed in order for the app to work correctly. Thanks, Caty On Fri, Nov 14, 2014 at 4:17 PM, Ecaterina Moraru (Valica) < [email protected]> wrote:
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/ta...
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
A.K.A. Welcome to Fragmentation https://en.wikipedia.org/wiki/Fragmentation_%28programming%29 -Eduard On Fri, Nov 14, 2014 at 4:17 PM, Ecaterina Moraru (Valica) < [email protected]> wrote:
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/ta...
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
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?) 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/ta...
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
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.... ;) [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
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/ta...
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
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.... ;) [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/ta...
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
participants (4)
-
Clemens Klein-Robbenhaar -
Ecaterina Moraru (Valica) -
Eduard Moraru -
Thomas Mortagne