[xwiki-devs] [Idea] Add XWiki version in xwiki.cfg during build
Hello all, Platform and Client team of XWiki SAS find interesting the idea of having XWiki version written as comment in the top of xwiki.cfg (no need for particular location though). When an upgrade is performed, it would permit to know if this configuration file has been merged (new xwiki version) or directly moved (first/previous xwiki version) from the old webapp. Do you think it would be feasible? Thank you in advance. Guillaume
On 07/29/2013 12:06 PM, Guillaume Fenollar wrote:
Hello all,
Platform and Client team of XWiki SAS find interesting the idea of having XWiki version written as comment in the top of xwiki.cfg (no need for particular location though). When an upgrade is performed, it would permit to know if this configuration file has been merged (new xwiki version) or directly moved (first/previous xwiki version) from the old webapp.
Do you think it would be feasible?
Thank you in advance.
Guillaume
Yes, it's quite easy to do. This file is already being generated by Maven during the build. -- Sergiu Dumitriu http://purl.org/net/sergiu
Hi Guillaume, On Jul 29, 2013, at 6:06 PM, Guillaume Fenollar <[email protected]> wrote:
Hello all,
Platform and Client team of XWiki SAS find interesting the idea of having XWiki version written as comment in the top of xwiki.cfg (no need for particular location though). When an upgrade is performed, it would permit to know if this configuration file has been merged (new xwiki version) or directly moved (first/previous xwiki version) from the old webapp.
Do you think it would be feasible?
How do you think it would work? * Imagine you have version N installed. * Now you've upgraded your WAR to version N+1 * You merge the xwiki configuration files . If you don't edit their versions you still have version N mentioned and it's even worse than before because the next person that comes will see and *trust* that you're at version N when you're actually at version N+1. I don't see how having a comment with the current version will help… I fear it might do the opposite... Actually the config file is supposed to stay stable as you're supposed to use the same config version across xwiki versions. In the future it'll need to be in the data dir (except for the location of the data dir which should be something defined in the startup script as it is now btw ;)). OTOH we could offer first some tools to upgrade the configuration files. We use sdiff for example to upgrade myxwiki.org: sudo mv xwiki.new/WEB-INF/web.xml xwiki.new/WEB-INF/web.xml.ori; sudo sdiff xwiki/WEB-INF/web.xml xwiki.new/WEB-INF/web.xml.ori -B -W -E -o xwiki.new/WEB-INF/web.xml sudo mv xwiki.new/WEB-INF/xwiki.cfg xwiki.new/WEB-INF/xwiki.cfg.ori; sudo sdiff xwiki/WEB-INF/xwiki.cfg xwiki.new/WEB-INF/xwiki.cfg.ori -B -W -E -o xwiki.new/WEB-INF/xwiki.cfg sudo mv xwiki.new/WEB-INF/xwiki.properties xwiki.new/WEB-INF/xwiki.properties.ori; sudo sdiff xwiki/WEB-INF/xwiki.properties xwiki.new/WEB-INF/xwiki.properties.ori -B -W -E -o xwiki.new/WEB-INF/xwiki.properties sudo mv xwiki.new/WEB-INF/struts-config.xml xwiki.new/WEB-INF/struts-config.xml.ori; sudo sdiff xwiki/WEB-INF/struts-config.xml xwiki.new/WEB-INF/struts-config.xml.ori -B -W -E -o xwiki.new/WEB-INF/struts-config.xml sudo mv xwiki.new/templates/admin.vm xwiki.new/templates/admin.vm.ori; sudo sdiff xwiki/templates/admin.vm xwiki.new/templates/admin.vm.ori -B -W -E -o xwiki.new/templates/admin.vm sudo mv xwiki.new/WEB-INF/classes/logback.xml xwiki.new/WEB-INF/classes/logback.xml.ori; sudo sdiff xwiki/WEB-INF/classes/logback.xml xwiki.new/WEB-INF/classes/logback.xml.ori -B -W -E -o xwiki.new/WEB-INF/classes/logback.xml That makes it quite easy to upgrade. For a further future, we could imagine offering a UI in an upgrade wizard (just before the distribution wizard runs) to let the user discover new configuration options, deprecated ones and removed ones. We would just need to add some metadata somewhere in XWiki to indicate that. Thanks -Vincent
Thank you in advance.
Guillaume
The first idea was to merge old configuration lines to the new xwiki.cfg, which means the version is correct when files are correctly merged. The issue is also that some lines need to be remove from xwiki.cfg (like workdir, which is useless in 5.x for example). Being able to follow the version number could be useful in this case. Upgrade wizard sounds nice BTW :) 2013/7/29 Vincent Massol <[email protected]>
Hi Guillaume,
On Jul 29, 2013, at 6:06 PM, Guillaume Fenollar < [email protected]> wrote:
Hello all,
Platform and Client team of XWiki SAS find interesting the idea of having XWiki version written as comment in the top of xwiki.cfg (no need for particular location though). When an upgrade is performed, it would permit to know if this configuration file has been merged (new xwiki version) or directly moved (first/previous xwiki version) from the old webapp.
Do you think it would be feasible?
How do you think it would work?
* Imagine you have version N installed. * Now you've upgraded your WAR to version N+1 * You merge the xwiki configuration files . If you don't edit their versions you still have version N mentioned and it's even worse than before because the next person that comes will see and *trust* that you're at version N when you're actually at version N+1.
I don't see how having a comment with the current version will help… I fear it might do the opposite...
Actually the config file is supposed to stay stable as you're supposed to use the same config version across xwiki versions. In the future it'll need to be in the data dir (except for the location of the data dir which should be something defined in the startup script as it is now btw ;)).
OTOH we could offer first some tools to upgrade the configuration files. We use sdiff for example to upgrade myxwiki.org:
sudo mv xwiki.new/WEB-INF/web.xml xwiki.new/WEB-INF/web.xml.ori; sudo sdiff xwiki/WEB-INF/web.xml xwiki.new/WEB-INF/web.xml.ori -B -W -E -o xwiki.new/WEB-INF/web.xml sudo mv xwiki.new/WEB-INF/xwiki.cfg xwiki.new/WEB-INF/xwiki.cfg.ori; sudo sdiff xwiki/WEB-INF/xwiki.cfg xwiki.new/WEB-INF/xwiki.cfg.ori -B -W -E -o xwiki.new/WEB-INF/xwiki.cfg sudo mv xwiki.new/WEB-INF/xwiki.properties xwiki.new/WEB-INF/xwiki.properties.ori; sudo sdiff xwiki/WEB-INF/xwiki.properties xwiki.new/WEB-INF/xwiki.properties.ori -B -W -E -o xwiki.new/WEB-INF/xwiki.properties sudo mv xwiki.new/WEB-INF/struts-config.xml xwiki.new/WEB-INF/struts-config.xml.ori; sudo sdiff xwiki/WEB-INF/struts-config.xml xwiki.new/WEB-INF/struts-config.xml.ori -B -W -E -o xwiki.new/WEB-INF/struts-config.xml sudo mv xwiki.new/templates/admin.vm xwiki.new/templates/admin.vm.ori; sudo sdiff xwiki/templates/admin.vm xwiki.new/templates/admin.vm.ori -B -W -E -o xwiki.new/templates/admin.vm sudo mv xwiki.new/WEB-INF/classes/logback.xml xwiki.new/WEB-INF/classes/logback.xml.ori; sudo sdiff xwiki/WEB-INF/classes/logback.xml xwiki.new/WEB-INF/classes/logback.xml.ori -B -W -E -o xwiki.new/WEB-INF/classes/logback.xml
That makes it quite easy to upgrade.
For a further future, we could imagine offering a UI in an upgrade wizard (just before the distribution wizard runs) to let the user discover new configuration options, deprecated ones and removed ones. We would just need to add some metadata somewhere in XWiki to indicate that.
Thanks -Vincent
Thank you in advance.
Guillaume
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Mon, Jul 29, 2013 at 6:42 PM, Vincent Massol <[email protected]> wrote:
Hi Guillaume,
On Jul 29, 2013, at 6:06 PM, Guillaume Fenollar < [email protected]> wrote:
Hello all,
Platform and Client team of XWiki SAS find interesting the idea of having XWiki version written as comment in the top of xwiki.cfg (no need for particular location though). When an upgrade is performed, it would permit to know if this configuration file has been merged (new xwiki version) or directly moved (first/previous xwiki version) from the old webapp.
Do you think it would be feasible?
How do you think it would work?
* Imagine you have version N installed. * Now you've upgraded your WAR to version N+1 * You merge the xwiki configuration files . If you don't edit their versions you still have version N mentioned and it's even worse than before because the next person that comes will see and *trust* that you're at version N when you're actually at version N+1.
I don't see how having a comment with the current version will help… I fear it might do the opposite...
I do not understand what you fear, a comment saying "Configuration file distributed with XWiki version x.y.z" could not really cause an issue to the merge process, and could help the way Guillaume said without causing any misinformation from our side anyway. Administrators could do tons of stupid things while merging, it does not matter.
Actually the config file is supposed to stay stable as you're supposed to use the same config version across xwiki versions. In the future it'll need to be in the data dir (except for the location of the data dir which should be something defined in the startup script as it is now btw ;)).
OTOH we could offer first some tools to upgrade the configuration files. We use sdiff for example to upgrade myxwiki.org:
sudo mv xwiki.new/WEB-INF/web.xml xwiki.new/WEB-INF/web.xml.ori; sudo sdiff xwiki/WEB-INF/web.xml xwiki.new/WEB-INF/web.xml.ori -B -W -E -o xwiki.new/WEB-INF/web.xml sudo mv xwiki.new/WEB-INF/xwiki.cfg xwiki.new/WEB-INF/xwiki.cfg.ori; sudo sdiff xwiki/WEB-INF/xwiki.cfg xwiki.new/WEB-INF/xwiki.cfg.ori -B -W -E -o xwiki.new/WEB-INF/xwiki.cfg sudo mv xwiki.new/WEB-INF/xwiki.properties xwiki.new/WEB-INF/xwiki.properties.ori; sudo sdiff xwiki/WEB-INF/xwiki.properties xwiki.new/WEB-INF/xwiki.properties.ori -B -W -E -o xwiki.new/WEB-INF/xwiki.properties sudo mv xwiki.new/WEB-INF/struts-config.xml xwiki.new/WEB-INF/struts-config.xml.ori; sudo sdiff xwiki/WEB-INF/struts-config.xml xwiki.new/WEB-INF/struts-config.xml.ori -B -W -E -o xwiki.new/WEB-INF/struts-config.xml sudo mv xwiki.new/templates/admin.vm xwiki.new/templates/admin.vm.ori; sudo sdiff xwiki/templates/admin.vm xwiki.new/templates/admin.vm.ori -B -W -E -o xwiki.new/templates/admin.vm sudo mv xwiki.new/WEB-INF/classes/logback.xml xwiki.new/WEB-INF/classes/logback.xml.ori; sudo sdiff xwiki/WEB-INF/classes/logback.xml xwiki.new/WEB-INF/classes/logback.xml.ori -B -W -E -o xwiki.new/WEB-INF/classes/logback.xml
That makes it quite easy to upgrade.
For a further future, we could imagine offering a UI in an upgrade wizard (just before the distribution wizard runs) to let the user discover new configuration options, deprecated ones and removed ones. We would just need to add some metadata somewhere in XWiki to indicate that.
Thanks -Vincent
Thank you in advance.
Guillaume
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
On Jul 30, 2013, at 11:48 AM, Denis Gervalle <[email protected]> wrote:
On Mon, Jul 29, 2013 at 6:42 PM, Vincent Massol <[email protected]> wrote:
Hi Guillaume,
On Jul 29, 2013, at 6:06 PM, Guillaume Fenollar < [email protected]> wrote:
Hello all,
Platform and Client team of XWiki SAS find interesting the idea of having XWiki version written as comment in the top of xwiki.cfg (no need for particular location though). When an upgrade is performed, it would permit to know if this configuration file has been merged (new xwiki version) or directly moved (first/previous xwiki version) from the old webapp.
Do you think it would be feasible?
How do you think it would work?
* Imagine you have version N installed. * Now you've upgraded your WAR to version N+1 * You merge the xwiki configuration files . If you don't edit their versions you still have version N mentioned and it's even worse than before because the next person that comes will see and *trust* that you're at version N when you're actually at version N+1.
I don't see how having a comment with the current version will help… I fear it might do the opposite...
I do not understand what you fear, a comment saying "Configuration file distributed with XWiki version x.y.z" could not really cause an issue to the merge process, and could help the way Guillaume said without causing any misinformation from our side anyway. Administrators could do tons of stupid things while merging, it does not matter.
I explained the risk in my mail but I was probably not clear. Summary: Having wrong doc is worse than having no doc. Details: Having a "Configuration file distributed with XWiki version x.y.z" information is pretty much useless since this file is **mean*t* to be modified so the information is only valid if you **don't** modify the file. As soon as you make one modification it's no longer valid and wrong/misleading for anyone who comes after and read it. Thanks -Vincent
Actually the config file is supposed to stay stable as you're supposed to use the same config version across xwiki versions. In the future it'll need to be in the data dir (except for the location of the data dir which should be something defined in the startup script as it is now btw ;)).
OTOH we could offer first some tools to upgrade the configuration files. We use sdiff for example to upgrade myxwiki.org:
sudo mv xwiki.new/WEB-INF/web.xml xwiki.new/WEB-INF/web.xml.ori; sudo sdiff xwiki/WEB-INF/web.xml xwiki.new/WEB-INF/web.xml.ori -B -W -E -o xwiki.new/WEB-INF/web.xml sudo mv xwiki.new/WEB-INF/xwiki.cfg xwiki.new/WEB-INF/xwiki.cfg.ori; sudo sdiff xwiki/WEB-INF/xwiki.cfg xwiki.new/WEB-INF/xwiki.cfg.ori -B -W -E -o xwiki.new/WEB-INF/xwiki.cfg sudo mv xwiki.new/WEB-INF/xwiki.properties xwiki.new/WEB-INF/xwiki.properties.ori; sudo sdiff xwiki/WEB-INF/xwiki.properties xwiki.new/WEB-INF/xwiki.properties.ori -B -W -E -o xwiki.new/WEB-INF/xwiki.properties sudo mv xwiki.new/WEB-INF/struts-config.xml xwiki.new/WEB-INF/struts-config.xml.ori; sudo sdiff xwiki/WEB-INF/struts-config.xml xwiki.new/WEB-INF/struts-config.xml.ori -B -W -E -o xwiki.new/WEB-INF/struts-config.xml sudo mv xwiki.new/templates/admin.vm xwiki.new/templates/admin.vm.ori; sudo sdiff xwiki/templates/admin.vm xwiki.new/templates/admin.vm.ori -B -W -E -o xwiki.new/templates/admin.vm sudo mv xwiki.new/WEB-INF/classes/logback.xml xwiki.new/WEB-INF/classes/logback.xml.ori; sudo sdiff xwiki/WEB-INF/classes/logback.xml xwiki.new/WEB-INF/classes/logback.xml.ori -B -W -E -o xwiki.new/WEB-INF/classes/logback.xml
That makes it quite easy to upgrade.
For a further future, we could imagine offering a UI in an upgrade wizard (just before the distribution wizard runs) to let the user discover new configuration options, deprecated ones and removed ones. We would just need to add some metadata somewhere in XWiki to indicate that.
Thanks -Vincent
Thank you in advance.
Guillaume
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Jul 30, 2013, at 11:57 AM, Vincent Massol <[email protected]> wrote:
On Jul 30, 2013, at 11:48 AM, Denis Gervalle <[email protected]> wrote:
On Mon, Jul 29, 2013 at 6:42 PM, Vincent Massol <[email protected]> wrote:
Hi Guillaume,
On Jul 29, 2013, at 6:06 PM, Guillaume Fenollar < [email protected]> wrote:
Hello all,
Platform and Client team of XWiki SAS find interesting the idea of having XWiki version written as comment in the top of xwiki.cfg (no need for particular location though). When an upgrade is performed, it would permit to know if this configuration file has been merged (new xwiki version) or directly moved (first/previous xwiki version) from the old webapp.
Do you think it would be feasible?
How do you think it would work?
* Imagine you have version N installed. * Now you've upgraded your WAR to version N+1 * You merge the xwiki configuration files . If you don't edit their versions you still have version N mentioned and it's even worse than before because the next person that comes will see and *trust* that you're at version N when you're actually at version N+1.
I don't see how having a comment with the current version will help… I fear it might do the opposite...
I do not understand what you fear, a comment saying "Configuration file distributed with XWiki version x.y.z" could not really cause an issue to the merge process, and could help the way Guillaume said without causing any misinformation from our side anyway. Administrators could do tons of stupid things while merging, it does not matter.
I explained the risk in my mail but I was probably not clear.
Summary: Having wrong doc is worse than having no doc.
Details: Having a "Configuration file distributed with XWiki version x.y.z" information is pretty much useless since this file is **mean*t* to be modified so the information is only valid if you **don't** modify the file. As soon as you make one modification it's no longer valid and wrong/misleading for anyone who comes after and read it.
And to reiterate on what I mentioned in my first reply, a much better solution IMO is: * Look for xwiki configuration files first in the permanent dir * If not found there, use the default config files provided with the WAR If we do this then: 1/ The user has its own config files in data/ 2/ The user can clearly see the config files related to the WAR version they got since they are distributed together Thanks -Vincent
Thanks -Vincent
Actually the config file is supposed to stay stable as you're supposed to use the same config version across xwiki versions. In the future it'll need to be in the data dir (except for the location of the data dir which should be something defined in the startup script as it is now btw ;)).
OTOH we could offer first some tools to upgrade the configuration files. We use sdiff for example to upgrade myxwiki.org:
sudo mv xwiki.new/WEB-INF/web.xml xwiki.new/WEB-INF/web.xml.ori; sudo sdiff xwiki/WEB-INF/web.xml xwiki.new/WEB-INF/web.xml.ori -B -W -E -o xwiki.new/WEB-INF/web.xml sudo mv xwiki.new/WEB-INF/xwiki.cfg xwiki.new/WEB-INF/xwiki.cfg.ori; sudo sdiff xwiki/WEB-INF/xwiki.cfg xwiki.new/WEB-INF/xwiki.cfg.ori -B -W -E -o xwiki.new/WEB-INF/xwiki.cfg sudo mv xwiki.new/WEB-INF/xwiki.properties xwiki.new/WEB-INF/xwiki.properties.ori; sudo sdiff xwiki/WEB-INF/xwiki.properties xwiki.new/WEB-INF/xwiki.properties.ori -B -W -E -o xwiki.new/WEB-INF/xwiki.properties sudo mv xwiki.new/WEB-INF/struts-config.xml xwiki.new/WEB-INF/struts-config.xml.ori; sudo sdiff xwiki/WEB-INF/struts-config.xml xwiki.new/WEB-INF/struts-config.xml.ori -B -W -E -o xwiki.new/WEB-INF/struts-config.xml sudo mv xwiki.new/templates/admin.vm xwiki.new/templates/admin.vm.ori; sudo sdiff xwiki/templates/admin.vm xwiki.new/templates/admin.vm.ori -B -W -E -o xwiki.new/templates/admin.vm sudo mv xwiki.new/WEB-INF/classes/logback.xml xwiki.new/WEB-INF/classes/logback.xml.ori; sudo sdiff xwiki/WEB-INF/classes/logback.xml xwiki.new/WEB-INF/classes/logback.xml.ori -B -W -E -o xwiki.new/WEB-INF/classes/logback.xml
That makes it quite easy to upgrade.
For a further future, we could imagine offering a UI in an upgrade wizard (just before the distribution wizard runs) to let the user discover new configuration options, deprecated ones and removed ones. We would just need to add some metadata somewhere in XWiki to indicate that.
Thanks -Vincent
Thank you in advance.
Guillaume
On Tue, Jul 30, 2013 at 12:01 PM, Vincent Massol <[email protected]> wrote:
On Jul 30, 2013, at 11:57 AM, Vincent Massol <[email protected]> wrote:
On Jul 30, 2013, at 11:48 AM, Denis Gervalle <[email protected]> wrote:
On Mon, Jul 29, 2013 at 6:42 PM, Vincent Massol <[email protected]>
wrote:
Hi Guillaume,
On Jul 29, 2013, at 6:06 PM, Guillaume Fenollar < [email protected]> wrote:
Hello all,
Platform and Client team of XWiki SAS find interesting the idea of
having
XWiki version written as comment in the top of xwiki.cfg (no need for particular location though). When an upgrade is performed, it would permit to know if this configuration file has been merged (new xwiki version) or directly moved (first/previous xwiki version) from the old webapp.
Do you think it would be feasible?
How do you think it would work?
* Imagine you have version N installed. * Now you've upgraded your WAR to version N+1 * You merge the xwiki configuration files . If you don't edit their versions you still have version N mentioned and it's even worse than before because the next person that comes will see and *trust* that you're at version N when you're actually at version N+1.
I don't see how having a comment with the current version will help… I fear it might do the opposite...
I do not understand what you fear, a comment saying "Configuration file distributed with XWiki version x.y.z" could not really cause an issue to the merge process, and could help the way Guillaume said without causing any misinformation from our side anyway. Administrators could do tons of stupid things while merging, it does not matter.
I explained the risk in my mail but I was probably not clear.
Summary: Having wrong doc is worse than having no doc.
It is not wrong doc for our distributed configuration files. So nothing to fear, this why I do not understand why you seems to be against that comment. What will be done with it later is up to the user, and you cannot prevent him to do stupid things.
Details: Having a "Configuration file distributed with XWiki version x.y.z"
information is pretty much useless since this file is **mean*t* to be modified so the information is only valid if you **don't** modify the file. As soon as you make one modification it's no longer valid and wrong/misleading for anyone who comes after and read it.
And to reiterate on what I mentioned in my first reply, a much better solution IMO is: * Look for xwiki configuration files first in the permanent dir * If not found there, use the default config files provided with the WAR
For sure, this is what we want. And the default file could keep a comment like the one I suggested, this is just the next step.
If we do this then: 1/ The user has its own config files in data/ 2/ The user can clearly see the config files related to the WAR version they got since they are distributed together
Thanks -Vincent
Thanks -Vincent
Actually the config file is supposed to stay stable as you're supposed to use the same config version across xwiki versions. In the future it'll need to be in the data dir (except for the location of the data dir which should be something defined in the startup script as it is now btw ;)).
OTOH we could offer first some tools to upgrade the configuration files. We use sdiff for example to upgrade myxwiki.org:
sudo mv xwiki.new/WEB-INF/web.xml xwiki.new/WEB-INF/web.xml.ori; sudo sdiff xwiki/WEB-INF/web.xml xwiki.new/WEB-INF/web.xml.ori -B -W -E -o xwiki.new/WEB-INF/web.xml sudo mv xwiki.new/WEB-INF/xwiki.cfg xwiki.new/WEB-INF/xwiki.cfg.ori; sudo sdiff xwiki/WEB-INF/xwiki.cfg xwiki.new/WEB-INF/xwiki.cfg.ori -B -W -E -o xwiki.new/WEB-INF/xwiki.cfg sudo mv xwiki.new/WEB-INF/xwiki.properties xwiki.new/WEB-INF/xwiki.properties.ori; sudo sdiff xwiki/WEB-INF/xwiki.properties xwiki.new/WEB-INF/xwiki.properties.ori -B -W -E -o xwiki.new/WEB-INF/xwiki.properties sudo mv xwiki.new/WEB-INF/struts-config.xml xwiki.new/WEB-INF/struts-config.xml.ori; sudo sdiff xwiki/WEB-INF/struts-config.xml xwiki.new/WEB-INF/struts-config.xml.ori -B -W -E -o xwiki.new/WEB-INF/struts-config.xml sudo mv xwiki.new/templates/admin.vm xwiki.new/templates/admin.vm.ori; sudo sdiff xwiki/templates/admin.vm xwiki.new/templates/admin.vm.ori -B -W -E -o xwiki.new/templates/admin.vm sudo mv xwiki.new/WEB-INF/classes/logback.xml xwiki.new/WEB-INF/classes/logback.xml.ori; sudo sdiff xwiki/WEB-INF/classes/logback.xml xwiki.new/WEB-INF/classes/logback.xml.ori -B -W -E -o xwiki.new/WEB-INF/classes/logback.xml
That makes it quite easy to upgrade.
For a further future, we could imagine offering a UI in an upgrade wizard (just before the distribution wizard runs) to let the user discover new configuration options, deprecated ones and removed ones. We would just need to add some metadata somewhere in XWiki to indicate that.
Thanks -Vincent
Thank you in advance.
Guillaume
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
On Jul 30, 2013, at 12:08 PM, Denis Gervalle <[email protected]> wrote:
On Tue, Jul 30, 2013 at 12:01 PM, Vincent Massol <[email protected]> wrote:
On Jul 30, 2013, at 11:57 AM, Vincent Massol <[email protected]> wrote:
On Jul 30, 2013, at 11:48 AM, Denis Gervalle <[email protected]> wrote:
On Mon, Jul 29, 2013 at 6:42 PM, Vincent Massol <[email protected]>
wrote:
Hi Guillaume,
On Jul 29, 2013, at 6:06 PM, Guillaume Fenollar < [email protected]> wrote:
Hello all,
Platform and Client team of XWiki SAS find interesting the idea of
having
XWiki version written as comment in the top of xwiki.cfg (no need for particular location though). When an upgrade is performed, it would permit to know if this configuration file has been merged (new xwiki version) or directly moved (first/previous xwiki version) from the old webapp.
Do you think it would be feasible?
How do you think it would work?
* Imagine you have version N installed. * Now you've upgraded your WAR to version N+1 * You merge the xwiki configuration files . If you don't edit their versions you still have version N mentioned and it's even worse than before because the next person that comes will see and *trust* that you're at version N when you're actually at version N+1.
I don't see how having a comment with the current version will help… I fear it might do the opposite...
I do not understand what you fear, a comment saying "Configuration file distributed with XWiki version x.y.z" could not really cause an issue to the merge process, and could help the way Guillaume said without causing any misinformation from our side anyway. Administrators could do tons of stupid things while merging, it does not matter.
I explained the risk in my mail but I was probably not clear.
Summary: Having wrong doc is worse than having no doc.
It is not wrong doc for our distributed configuration files. So nothing to fear, this why I do not understand why you seems to be against that comment. What will be done with it later is up to the user, and you cannot prevent him to do stupid things.
This file is not distributed separately. We always distribute it with our WAR and thus it already has a version: the one of the WAR. I don't see what would be provided more by adding a version info in it. However I can easily see what can go wrong by doing that. Guillaume said: "When an upgrade is performed, it would permit to know if this configuration file has been merged (new xwiki version) or directly moved (first/previous xwiki version) from the old webapp." But I fail to see how adding the version would help for this, except if the user updates the version comment himself after he merges with the new version. But he can do already by adding a comment… Thanks -Vincent
Details: Having a "Configuration file distributed with XWiki version x.y.z" information is pretty much useless since this file is **mean*t* to be modified so the information is only valid if you **don't** modify the file. As soon as you make one modification it's no longer valid and wrong/misleading for anyone who comes after and read it.
And to reiterate on what I mentioned in my first reply, a much better solution IMO is: * Look for xwiki configuration files first in the permanent dir * If not found there, use the default config files provided with the WAR
For sure, this is what we want. And the default file could keep a comment like the one I suggested, this is just the next step.
If we do this then: 1/ The user has its own config files in data/ 2/ The user can clearly see the config files related to the WAR version they got since they are distributed together
Thanks -Vincent
Thanks -Vincent
Actually the config file is supposed to stay stable as you're supposed to use the same config version across xwiki versions. In the future it'll need to be in the data dir (except for the location of the data dir which should be something defined in the startup script as it is now btw ;)).
OTOH we could offer first some tools to upgrade the configuration files. We use sdiff for example to upgrade myxwiki.org:
sudo mv xwiki.new/WEB-INF/web.xml xwiki.new/WEB-INF/web.xml.ori; sudo sdiff xwiki/WEB-INF/web.xml xwiki.new/WEB-INF/web.xml.ori -B -W -E -o xwiki.new/WEB-INF/web.xml sudo mv xwiki.new/WEB-INF/xwiki.cfg xwiki.new/WEB-INF/xwiki.cfg.ori; sudo sdiff xwiki/WEB-INF/xwiki.cfg xwiki.new/WEB-INF/xwiki.cfg.ori -B -W -E -o xwiki.new/WEB-INF/xwiki.cfg sudo mv xwiki.new/WEB-INF/xwiki.properties xwiki.new/WEB-INF/xwiki.properties.ori; sudo sdiff xwiki/WEB-INF/xwiki.properties xwiki.new/WEB-INF/xwiki.properties.ori -B -W -E -o xwiki.new/WEB-INF/xwiki.properties sudo mv xwiki.new/WEB-INF/struts-config.xml xwiki.new/WEB-INF/struts-config.xml.ori; sudo sdiff xwiki/WEB-INF/struts-config.xml xwiki.new/WEB-INF/struts-config.xml.ori -B -W -E -o xwiki.new/WEB-INF/struts-config.xml sudo mv xwiki.new/templates/admin.vm xwiki.new/templates/admin.vm.ori; sudo sdiff xwiki/templates/admin.vm xwiki.new/templates/admin.vm.ori -B -W -E -o xwiki.new/templates/admin.vm sudo mv xwiki.new/WEB-INF/classes/logback.xml xwiki.new/WEB-INF/classes/logback.xml.ori; sudo sdiff xwiki/WEB-INF/classes/logback.xml xwiki.new/WEB-INF/classes/logback.xml.ori -B -W -E -o xwiki.new/WEB-INF/classes/logback.xml
That makes it quite easy to upgrade.
For a further future, we could imagine offering a UI in an upgrade wizard (just before the distribution wizard runs) to let the user discover new configuration options, deprecated ones and removed ones. We would just need to add some metadata somewhere in XWiki to indicate that.
Thanks -Vincent
Thank you in advance.
Guillaume
On Tue, Jul 30, 2013 at 12:30 PM, Vincent Massol <[email protected]> wrote:
On Jul 30, 2013, at 12:08 PM, Denis Gervalle <[email protected]> wrote:
On Tue, Jul 30, 2013 at 12:01 PM, Vincent Massol <[email protected]> wrote:
On Jul 30, 2013, at 11:57 AM, Vincent Massol <[email protected]>
wrote:
On Jul 30, 2013, at 11:48 AM, Denis Gervalle <[email protected]> wrote:
On Mon, Jul 29, 2013 at 6:42 PM, Vincent Massol <[email protected]>
wrote:
Hi Guillaume,
On Jul 29, 2013, at 6:06 PM, Guillaume Fenollar < [email protected]> wrote:
> Hello all, > > Platform and Client team of XWiki SAS find interesting the idea of
having
> XWiki version written as comment in the top of xwiki.cfg (no need
for
> particular location though). > When an upgrade is performed, it would permit to know if this configuration > file has been merged (new xwiki version) or directly moved (first/previous > xwiki version) from the old webapp. > > Do you think it would be feasible?
How do you think it would work?
* Imagine you have version N installed. * Now you've upgraded your WAR to version N+1 * You merge the xwiki configuration files . If you don't edit their versions you still have version N mentioned and it's even worse than before because the next person that comes will see and *trust* that you're at version N when you're actually at version N+1.
I don't see how having a comment with the current version will help… I fear it might do the opposite...
I do not understand what you fear, a comment saying "Configuration file distributed with XWiki version x.y.z" could not really cause an issue to the merge process, and could help the way Guillaume said without causing any misinformation from our side anyway. Administrators could do tons of stupid things while merging, it does not matter.
I explained the risk in my mail but I was probably not clear.
Summary: Having wrong doc is worse than having no doc.
It is not wrong doc for our distributed configuration files. So nothing to fear, this why I do not understand why you seems to be against that comment. What will be done with it later is up to the user, and you cannot prevent him to do stupid things.
This file is not distributed separately. We always distribute it with our WAR and thus it already has a version: the one of the WAR. I don't see what would be provided more by adding a version info in it. However I can easily see what can go wrong by doing that.
In production, since currently configuration files are in the war and should be customized, we need to unzip the war, and therefore the configuration file does not have anymore a version the way you seems to expect. I still do not understand why you fear that much to state in a file what is it really.
Guillaume said:
"When an upgrade is performed, it would permit to know if this configuration file has been merged (new xwiki version) or directly moved (first/previous xwiki version) from the old webapp."
But I fail to see how adding the version would help for this, except if the user updates the version comment himself after he merges with the new version. But he can do already by adding a comment…
If you proceed to an automated tree-way merge, based on, let say: "Configuration file distributed with XWiki version a.b.c" in the original war for version n-1 "Customized configuration file for XWiki version a.b.c" in your old webapp "Configuration file distributed with XWiki version x.y.z" in the new war for version n You will surely god what Guillaume expects, which would be "Customized configuration file for XWiki version x.y.z", and will allow to differentiate this file from the simple copy of the file from the old webapp. So, the point of Guillaume is not that bad when used properly.
Thanks -Vincent
Details: Having a "Configuration file distributed with XWiki version x.y.z" information is pretty much useless since this file is **mean*t* to be modified so the information is only valid if you **don't** modify the file. As soon as you make one modification it's no longer valid and wrong/misleading for anyone who comes after and read it.
And to reiterate on what I mentioned in my first reply, a much better solution IMO is: * Look for xwiki configuration files first in the permanent dir * If not found there, use the default config files provided with the WAR
For sure, this is what we want. And the default file could keep a comment like the one I suggested, this is just the next step.
If we do this then: 1/ The user has its own config files in data/ 2/ The user can clearly see the config files related to the WAR version they got since they are distributed together
Thanks -Vincent
Thanks -Vincent
Actually the config file is supposed to stay stable as you're supposed to use the same config version across xwiki versions. In the future it'll need to be in the data dir (except for the location of the data dir which should be something defined in the startup script as it is now btw ;)).
OTOH we could offer first some tools to upgrade the configuration files. We use sdiff for example to upgrade myxwiki.org:
sudo mv xwiki.new/WEB-INF/web.xml xwiki.new/WEB-INF/web.xml.ori; sudo sdiff xwiki/WEB-INF/web.xml xwiki.new/WEB-INF/web.xml.ori -B -W -E -o xwiki.new/WEB-INF/web.xml sudo mv xwiki.new/WEB-INF/xwiki.cfg xwiki.new/WEB-INF/xwiki.cfg.ori; sudo sdiff xwiki/WEB-INF/xwiki.cfg xwiki.new/WEB-INF/xwiki.cfg.ori -B -W -E -o xwiki.new/WEB-INF/xwiki.cfg sudo mv xwiki.new/WEB-INF/xwiki.properties xwiki.new/WEB-INF/xwiki.properties.ori; sudo sdiff xwiki/WEB-INF/xwiki.properties xwiki.new/WEB-INF/xwiki.properties.ori -B -W -E -o xwiki.new/WEB-INF/xwiki.properties sudo mv xwiki.new/WEB-INF/struts-config.xml xwiki.new/WEB-INF/struts-config.xml.ori; sudo sdiff xwiki/WEB-INF/struts-config.xml xwiki.new/WEB-INF/struts-config.xml.ori -B -W -E -o xwiki.new/WEB-INF/struts-config.xml sudo mv xwiki.new/templates/admin.vm xwiki.new/templates/admin.vm.ori; sudo sdiff xwiki/templates/admin.vm xwiki.new/templates/admin.vm.ori -B -W -E -o xwiki.new/templates/admin.vm sudo mv xwiki.new/WEB-INF/classes/logback.xml xwiki.new/WEB-INF/classes/logback.xml.ori; sudo sdiff xwiki/WEB-INF/classes/logback.xml xwiki.new/WEB-INF/classes/logback.xml.ori -B -W -E -o xwiki.new/WEB-INF/classes/logback.xml
That makes it quite easy to upgrade.
For a further future, we could imagine offering a UI in an upgrade wizard (just before the distribution wizard runs) to let the user discover new configuration options, deprecated ones and removed ones. We would just need to add some metadata somewhere in XWiki to indicate that.
Thanks -Vincent
> Thank you in advance. > > Guillaume
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
participants (4)
-
Denis Gervalle -
Guillaume Fenollar -
Sergiu Dumitriu -
Vincent Massol