Thank Jukka! I am not sure that I can fill in a bug yet, because I cannot reproduce the problem. Probably it was originated in incompatible repository versions.
Many thanks for describing the version policy. It makes a lot of sense. And I've been also thinking about the export/import functionality as the single standard way of assurin content upgrades. Though, this task can be really tedious considering a very very big repository. Add to this some binary content, and I am quite sure that the export/import would need more than 4Gb of RAM for creating and writting the XML, or a very good strategy to slice the content. However, I have to agree with you that there are no other possibilities :-(. once again many thanks, ./alex -- .w( the_mindstorm )p. On 3/15/06, Jukka Zitting <[EMAIL PROTECTED]> wrote: > > Hi, > > I'm not sure I can help you with the problem you were facing. Can you > file a bug report with steps to reproduce? I'll comment on the release > versioning questions though. > > On 3/15/06, Alexandru Popescu <[EMAIL PROTECTED]> wrote: > > The questions now: > > - why do these incompatibilities appear when upgrading jackrabbit > version? > > - what is the way to recover content before/after an upgrade? > > - are there any known solutions for this kind of problem? > > - is this gonna be a problem in the future? > > So far there have been no guarantees on backwards compatibility, even > the 0.9 release explicitly warned about possible compatibility issues > when upgrading to 1.0. This is however going to change once the 1.0 > release is out. > > The plan is to adopt a three-level MAJOR.MINOR.PATCH versioning > scheme, where each PATCH version (like 1.0.x) will be drop-in > compatible with other versions of the same MINOR release. PATCH > releases will be made from the MINOR release branches to fix reported > bugs, but will contain no new features or non-compatible changes. It > should always be possible to switch between PATCH releases by just > changing the jar files and restarting Jackrabbit. > > The MINOR releases can contain new features and other internal changes > but should not break binary compatibility with clients that only use > the JCR and org.apache.jackrabbit.api interfaces. It is possible > (although not preferred) that a MINOR release upgrade will require a > system view export/import or a similar backup/restore procedure for > existing content and configuration, but clear instructions on doing so > will be included in the release notes if something like that is > needed. > > MAJOR releases may contain changes to the client APIs and extensive > internal modifications. The foreseeable future for Jackrabbit is to > release 2.0 for the JCR 2.0 API in 2007 when the JSR-283 is final. > > I hope this answers your questions. > > BR, > > Jukka Zitting > > -- > Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED] > Software craftsmanship, JCR consulting, and Java development >
