Hi Pavel, On Jul 13, 2007, at 10:41 AM, Pavel wrote: We do all this already... :) It's either available in our release notes or directly at the source in our SVN repository which you can browse and query here: http://fisheye.xwiki.org. For example you can give it a date range (between 2 releases and it'll tell you all that have changed). Thanks -Vincent -- You receive this message as a subscriber of the xwiki-users(a)objectweb.orgmailing list. To unsubscribe: mailto:xwiki-users-unsubscribe@objectweb.org For general help: mailto:sympa@objectweb.org?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

On Jul 13, 2007, at 11:38 PM, Pavel wrote: Vincent, I was talking about deployment-specific modifications that one can make to skin, config, etc. On developer side I'm pretty sure your VCS is capable of tracking changes =). Everything is in the SCM, including skin, configs, etc. Now if you're not interested in details, we have the release notes which point out the important items. It's possible (and probable) we miss things from time to time so don't hesitate to tell us/help us improve them. Thanks -Vincent On 7/13/07, Vincent Massol &lt;vincent(a)massol.net&gt; wrote: -- Best regards, Pavel -- You receive this message as a subscriber of the xwiki-users(a)objectweb.orgmailing list. To unsubscribe: mailto:xwiki-users-unsubscribe@objectweb.org<xwiki-users-unsubscribe@objectweb.org> For general help: mailto:sympa@objectweb.org?subject=help<sympa@objectweb.org?subject=help> ObjectWeb mailing lists service home page: http://www.objectweb.org/wws -- You receive this message as a subscriber of the xwiki-users(a)objectweb.orgmailing list. To unsubscribe: mailto:xwiki-users-unsubscribe@objectweb.org For general help: mailto:sympa@objectweb.org?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

I did the same until I realized that neither of these is efficient. What I do now, is leave the base skin unchanged, and only write a few files that override/extend the official skin. For example, I write an additional colors<projectname>.css file to change the colors of the skin, <projectname>.css for other look changes, and override a few vm templates. Then I change xwiki.cfg to set the default skin to point to the directory containing my files, and defaultbaseskin to point to albatross. On 7/15/07, Pavel &lt;pagrus(a)gmail.com&gt; wrote: Sergiu -- http://purl.org/net/sergiu -- You receive this message as a subscriber of the xwiki- users(a)objectweb.org mailing list. To unsubscribe: mailto:xwiki-users-unsubscribe@objectweb.org For general help: mailto:sympa@objectweb.org?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/ wws

Hi Pavel, I understand now... :) I have 3 comments on that: 1) The current xwiki skins are not made for extensibility/ modifications. We have some jira tasks to refactor them so that they can be more easily modified. This would help. 2) In the further future, we have plan for UI component which would allow you to modify any part of xwiki without touching existing code. But that's probably for next year... 3) Right now, I suggest that you do the following: - make your changes to the skin - create a patch out of it and keep it - use the skin from the new version - apply your patch This is a variation to your second scenario but in a more automated way. -Vincent On Jul 14, 2007, at 11:49 PM, Pavel wrote: > True, true, true. I'm not arguing at all, just trying to point out > that we speak about different things. Something must be wrong with > my ability to explain. > > Let me try again, this time with scenario. > > Lets say I've installed Xwiki 1.0. I also made a change or two to > Albatross skin. Some time later you and XWiki team releases XWiki > 1.5 that I want to upgrade to. Lets say there are 20 fixes/ > improvements in Albatross between these two versions. > > I see two ways to perform the upgrade: > 1. Install 1.5 > 2a. Copy modified Albatross skin from 1.0 > 3a. Go to subversion, diff the 1.0 and 1.5 versions > 4a. Identify those 20 changes and apply them to Albatross skin. > > Alternative scenario is > 1. Install 1.5 > 2b. Identify local changes made in Albatross 1.0 > 3b. Apply those changes to Albatross 1.5 > > For "b" way the life for me would be much easier if I tracked all > the local customizations. That would eliminate the [most painful] > step 2b. > > So my advice was to keep track of local changes thus saving efforts > for "b" way. The advice addressed to XWiki users, not developers of > course. And it is not supposed to mean any problems with XWiki itself. > It is not even about XWiki, it is about maintaining any software > one is not in control of. > > On 7/14/07, Vincent Massol < vincent(a)massol.net&gt; wrote: > > On Jul 13, 2007, at 11:38 PM, Pavel wrote: > >> Vincent, >> >> I was talking about deployment-specific modifications that one can >> make to skin, config, etc. >> On developer side I'm pretty sure your VCS is capable of tracking >> changes =). > > Everything is in the SCM, including skin, configs, etc. > > Now if you're not interested in details, we have the release notes > which point out the important items. It's possible (and probable) > we miss things from time to time so don't hesitate to tell us/help > us improve them. > > Thanks > -Vincent > >> On 7/13/07, Vincent Massol &lt;vincent(a)massol.net&gt; wrote: >> Hi Pavel, >> >> On Jul 13, 2007, at 10:41 AM, Pavel wrote: >> >> > I'm not Xwiki developer and cannot answer directly your question, >> > but based >> > on my own experience the following would be a good idea: >> > >> > Somehow record all changes that you make to skins, config, other >> > static >> > resources. >> > While there are certain means to migrate db content to newer Xwiki >> > versions, >> > other changes are up to you. >> > Having a list of those may save you lots of your time. At leas you >> > will know >> > what and where to reapply. >> >> We do all this already... :) >> >> It's either available in our release notes or directly at the source >> in our SVN repository which you can browse and query here: >> http://fisheye.xwiki.org. For example you can give it a date range >> (between 2 releases and it'll tell you all that have changed). >> >> Thanks >> -Vincent >> >> > -----Original Message----- >> > From: wangwh(a)att.net [mailto:wangwh@att.net] >> > Sent: Friday, July 13, 2007 1:51 AM >> > To: xwiki-users(a)objectweb.org >> > Subject: [xwiki-users] XWiki upgrades path? >> > >> > Hi, XWiki team, >> > >> > It seems to me that upgrading the XWiki version on XWiki farm is >> > very hard >> > to do since it is not done for quite some time. Is this an >> > indicator that >> > maintaining an XWiki server with live sites is not easy? >> > >> > Is there a path for site managers to move up to the next version >> > XWiki? Or, >> > is there a way for users to get to the new version or get around >> the >> > problems of the old version? Not everyday everyone is starting from >> > a clean >> > new version, everyone has to face the upgrading time. If XWiki >> > farm sites >> > have to stay in old, old version, I guess moving up is really >> > difficult. It >> > does not look good to potential new users. >> > >> > Thanks for thinking about this issue. >> > Wei-hsing >> >

What do you mean by 'create a patch'? Is this something more than saving away any vm files that I changed? Can you elaborate?

wangwh(a)att.net escribió: Hi, Wei-hsing, I think your question is quite pertinent, but we can find part of the answer in some previous messages from XWiki developers. For instance, read this from Vincent... "First, as you've asked about the distinctions it means the description on the download page isn't good enough so that needs to be improved. I wouldn't mind getting your help for that :)" XWiki is quickly changing/improving, so at this stage if is not easy to give a clear update workflow. In what concern updates when changes in the database are not implied, I think the process is so easy as to install the new release and point it to the already created database. Particular care must be taken in what concern to changes in configuration files and/scripts and while importing files from a new xar (xwiki-application-panels-1.1-milestone-3.xar) file. All this must be reflected in this download page, or in a page clearly linked to it. But this is a work to be done and to what all contributions will be welcome! I do hope dev people agree with this paragraph :-)