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 <pagrus(a)gmail.com> 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> 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 <vincent(a)massol.net> 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
> > >
> > >
> > >