Bug 34088

it may be useful to create patch files in either xupdate of xpatch format (since
they both ship with lenya already)

Created attachment 14522 [details]
Patch to upgrade publications based on the default publication from 1.2 to 1.4. Patch is relative to the root of the default publication

(In reply to comment #2)
> Created an attachment (id=14522) [edit]
> Patch to upgrade publications based on the default publication from 1.2 to 1.4
> 

the above patch is a first cut at a patch to upgrade an instance of a 1.2
publication based on the default publication to 1.4. it has the following
changes relative to a straight diff between the two branches:

* ignores content files
* removes default/ prefix to enable patching of publications with other names

ideally, someone would give it a try..

solprovider@gmail.com wrote:

> 5) Upgrading causes headaches.
> This is difficult for all software.  Some companies/projects just
> announce old implementations will not work with the latest release;
> those companies tend to disappear.
> 
> My company details how each code change will affect the previous
> release, and if so, requires the patch to fix the upgrade process too.
>  We do require upgrades to every release; each upgrade only handles
> the last release; but we release seldom enough (and the upgrades are
> free) so all of our customers have upgraded before the next release.
> 
> Lenya is more complicated because of parallel development.  Will
> everybody need to upgrade 1.2.2 to 1.2.3 to 1.2.4 to be able to
> upgrade to 1.4?  This could be required if upgrades were easy, but the
> 1.2.2 to 1.2.3 upgrade issues will hurt.  Lenya1.4 needs upgrade code
> for each 1.2 release starting with 1.2.2.  There will be milestone
> releases where all the upgrade code is discarded.
> 
> Our process loops through each document, and calls the appropriate
> upgrade function.  The functions only deal with one type of document. 
> Lenya should have an upgrade process for XSL, XSP, JS, XMAP, IML and
> GML, various XCONF, siteree.xml, content XML, Flow Form XML, and more.
>  Each file should be considered as a data during upgrade.  Some is
> easy.  Modifications outside a publication should be discarded; anyone
> who customizes the main program must remember their changes, except
> maybe the publication "upgrade XSL" could be applied to the global XSL
> (for "login" and "choose publication") XSL if those documents have not
> changed much.  Creating a framework for this is a chore, but it should
> only need to done once.  Hopefully Lenya can implement something
> similar, and figure out how to make it mandatory for each patch to
> keep it current.

Upgrade process should attempt to upgrade all publications.  First line of the
upgrade instructions should be "1. Backup your old installation, including all
publications, now!"

Even better would be to copy all pubs from the "pubs" directory to a
"pubs-{oldversion}" directory before upgrading.  If the upgrade fails, they can
reinstall the last version and just copy the old pubs directory to regain
usefulness.  That may require a choice from the user; if they already backed up
everything, they may not want to waste disk space, or even have it to be wasted.

just a warning: everything here is very likely totally outdated. should we
really try and provide an automated migration path? sounds hard if not impossible.

We could certainly provide a migration tool for the content, but not for the
publication "infrastructure" (sitemaps, XSLTs etc.).

(In reply to comment #7)
> We could certainly provide a migration tool for the content, but not for the
> publication "infrastructure" (sitemaps, XSLTs etc.).

will your migration test be adaptable to this?
as to the infrastructure, we should make sure that once the content has been
migrated, the user immediately sees something, i.e. the websites should render
somehow (maybe display a prettyprinted source), and the GUI should not produce
NPEs when the user clicks around... will this be a target for 2.0 or afterwards?

(In reply to comment #8)
> (In reply to comment #7)
> > We could certainly provide a migration tool for the content, but not for the
> > publication "infrastructure" (sitemaps, XSLTs etc.).
> 
> will your migration test be adaptable to this?

Yes, provided that the publication doesn't use a custom DocumentIdToPathMapper.

> as to the infrastructure, we should make sure that once the content has been
> migrated, the user immediately sees something, i.e. the websites should render
> somehow (maybe display a prettyprinted source), and the GUI should not produce
> NPEs when the user clicks around... will this be a target for 2.0 or afterwards?

Good question. I'm quite busy at the moment, so I can't promise to deliver any
code soon. If you'd like to give it a try, please don't hesitate.

removed the [PATCH] from the subject since it's ages old and won't be any use
for the current 2.0 trunk.