[Scribus] XML format used in Scribus

[PLinnell]

On Saturday 14 May 2005 22:11, Louis Desjardins wrote:
> >On Saturday 14 May 2005 20:41, Gregory Pittman wrote:
> >  > Craig Bradney wrote:
>
> [snip]
>
> >>  What I think it comes down to is the issue of
> >>  intentionally/unintentionally setting up barriers to the use of
> >>  (and happiness with) Scribus.  A backup plan can always be to
> >> at least have a parsable format so that some utility can help
> >> with problems, and maybe even yield unanticipated benefits.
> >
> >Oh, we certainly do recognize this. No intentional barriers are
> >intended.  Just the going from 1.3+ backsaving to  < 1.2.x is not
> > a high priority IMNSHO.
> >
> >Peter
>
> May I suggest we inherit these concerns from the proprietary
> software world? Since upgrading to the next version of Scribus
> doesn't imply any money (but a little time, yes!), it is reasonable
> to assume there is no real barrier to upgrading? 

The only barriers we encounter with upgrading is when a particular 
user's distro does not have new enough versions of libraries to 
support the current version of Scribus. Mind you we don't break 
backwards compatibility without some consideration of what users have 
now. 

A good example is Franz did some work arounds to keep 1.2 stable 
useful for folks with older Qt 3.0.x versions. We have wanted to 
require Qt 3.3.x for a long time, but waited until 1.3.0cvs was 
released. 

We also waited for a while to insist on GCC 3.x. Much longer than we 
would have liked to. During that time our consideration at the time 
that doing so would certainly break building Scribus on debian 
stable. Finally, needed optimizations/c++ correctness forced our 
hand.

>Then why simply not upgrade? The real issue, imo, is having old files 
being able to  be opened by a newer version. The way around seems to 
me a bit like  a programming challenge, but not an issue for users.
>

We have done I think a good job of preserving the ability to open much 
older documents in current 1.2.2cvs and even 1.3. This is something 
which is tested prior to each release. Funny enough, I was testing 
this today in preparation for releasing 1.2.2.

> On the other hand, in the proprietary world, where all upgrades are
> costly, then someone might have an older version and no will to
> upgrade, and will eventually be given no other choice than upgrade
> if he/she wants to open a more recent file.
>
> Am I missing something?
>
> Louis
> _______________________________________________

Upgrades can be extraordinarily expensive in the proprietary world, 
not just in cost, but testing time and other issues. 

I think this is where we beat the competitive world in DTP. Our 
transparency and attention to these details without even users asking 
is sometimes not so evident though.

Peter