Bug 34088 - Provide patch to upgrade publications from 1.2 to 2.0
Provide patch to upgrade publications from 1.2 to 2.0
Status: NEW
Product: Lenya
Classification: Unclassified
Component: Build System
unspecified
Other other
: P2 normal
: 2.0.1
Assigned To: Lenya Developers
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2005-03-19 20:22 UTC by Gregor J. Rothfuss
Modified: 2008-01-10 12:39 UTC (History)
0 users



Attachments
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 (147.29 KB, patch)
2005-03-20 23:35 UTC, Gregor J. Rothfuss
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Gregor J. Rothfuss 2005-03-19 20:22:38 UTC
It should be possible to automate a lot of the small changes required to make a
1.2 publication work in 1.4.

svn diff https://svn.apache.org/repos/a
sf/lenya/branches/BRANCH_1_2_X/src/webapp/lenya/pubs https://svn.apache.org/repo
s/asf/lenya/trunk/src/webapp/lenya/pubs > diff.txt

to ensure that patches apply cleanly to custom publications, it may be necessary
to use xmldiff or a similar tool.
Comment 1 Gregor J. Rothfuss 2005-03-19 20:47:10 UTC
it may be useful to create patch files in either xupdate of xpatch format (since
they both ship with lenya already)
Comment 2 Gregor J. Rothfuss 2005-03-20 23:35:37 UTC
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
Comment 3 Gregor J. Rothfuss 2005-03-20 23:38:20 UTC
(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..
Comment 4 Gregor J. Rothfuss 2005-06-07 15:59:21 UTC
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.
Comment 5 solprovider 2005-06-07 18:15:05 UTC
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.
Comment 6 J 2007-04-25 10:27:06 UTC
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.
Comment 7 Andreas Hartmann 2007-04-26 00:07:19 UTC
We could certainly provide a migration tool for the content, but not for the
publication "infrastructure" (sitemaps, XSLTs etc.).
Comment 8 J 2007-08-02 14:25:36 UTC
(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?
Comment 9 Andreas Hartmann 2007-08-03 01:39:15 UTC
(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.

Comment 10 J 2007-10-29 10:13:16 UTC
removed the [PATCH] from the subject since it's ages old and won't be any use
for the current 2.0 trunk.