Scribus version and compatibility confusion
As a first time Scribus user two things troubled me. For starters I couldn't grasp the order in which versions were made available. And for second I was confused regarding backward compatability. Different sources like readme, online manual en faq mention something about backward compatibility. But in such a way I had trouble comprehending it. On top of it searching for a definition of "backward compatibility" different sources all define it differently. I even get the impression a wikipedia article about it contradicts itself. So I'll try to make two things a bit clearer for at least my self :)
1. What's with the scribus versioning scheme / scribus versioning convention?
2. Will a later version of Scribus be able to load a data file created by an earlier version?
To get an answer to my questions I used a searchengine and finally found the answer to the first question in some mailinglist archive. To get a definite answer on my second question I used IRC.
>>no one's working on 4 versions of Scribus. 1.3.3.x is the stable series and
>>will receive bugfixes until a new stable version is out. 1.3.4 is available,
>>but work continues in the 1.3.5 development tree.
>
> I know that various OS projects use different versioning conventions,
> e.g. odd numbers are stable releases and even numbers are development
> releases. The above quote is a little mind-boggling. V. 1.3.39 is
> being bug-fixed (=patched, maintained) and is the stable release. V.
> 1.3.5 is being developed. So what is the status of 1.3.4? A
> dead-end branch, stable, a big mistake, a dev version or what? I
> think this question is what lies behind the remark "Too many releases".
We also use the even/odd versioning scheme, so
1.2.x - stable
1.3.x - development
1.4.x - stable
1.5.x - development
Unfortunately, when developing version 1.3.3, we realized that
a) most users used the latest development release (1.3.2 or 1.3.3) instead of 1.2
b) we needed to break some things really badly in the next development release (1.3.4)
So we just declared 1.3.3.x as the latest stable version (that's why I also call it a stabilized development version) and have been releasing minor stable version 1.3.3.x ever since.
Then we went on and broke lots of stuff in the 1.3.4 development version.
Still, some users use that version...
After that, we ported Scribus from Qt3 to Qt4, that took a long time and we had to rewrite lots of code. During that time we also fixed a lot of the bugs present in 1.3.4, and accepted additional contributions (two GSoC projects: LaTeX frames and imposition, aspell plugin). So we hope that, when it's released, 1.3.5 will be a better 1.3.4 - but still a development version.
I think we'll also rework our roadmap: lot's of the stuff is going to be moved to 1.5.x so we can release a stable 1.4 earlier. Missing stuff before 1.4 is mainly fileformat changes and internal object model.
My guess is we'll see 1.3.6, 1.3.7 and 1.3.8 and then 1.4.
/Andreas
-- Fri Jan 4 08:41:07 CET 2008
>>no one's working on 4 versions of Scribus. 1.3.3.x is the stable series and
>>will receive bugfixes until a new stable version is out. 1.3.4 is available,
>>but work continues in the 1.3.5 development tree.
>
> I know that various OS projects use different versioning conventions,
> e.g. odd numbers are stable releases and even numbers are development
> releases. The above quote is a little mind-boggling. V. 1.3.39 is
> being bug-fixed (=patched, maintained) and is the stable release. V.
> 1.3.5 is being developed. So what is the status of 1.3.4? A
> dead-end branch, stable, a big mistake, a dev version or what? I
> think this question is what lies behind the remark "Too many releases".
When 1.2.x was still around, we found too many people wanted the features of 1.3.0+ to be stabilised, and it was very stable for a development branch.. so we stabilised at 1.3.3. and have made that series (up to the soon to be released 1.3.3.10 and higher) our stable series.
1.3.4 was a major change of a lot of things and just the next development release after 1.3.0, 1.3.1, 1.3.2, 1.3.3. 1.3.5 simply continues after 1.3.4 and as such all fixes for 1.3.4 are going into 1.3.5.
Once we decide to stop changing/adding things, we will fix the versioning and release a 1.4.x stable and move to 1.5.x development, but until we decide to do that, its 1.3.3.x for stable and 1.3.4+ (now 1.3.5) for
development.
Craig
-- Fri Jan 4 08:31:59 CET 2008
> I have just downloaded and installed 1.3.3.10 and 1.3.4, last one
> because i have read there are big improvements.
>
> What should i expect from 1.3.4?, should i download 1.3.5?
> I?m using scribus for the last 3 or 4 months and i'm more than
> satisfied (except for some hangs wich i think could be me going too
> fast), but i want to squeeze it's features as much as possible, i have
> found 1.3.4 is faster to load a document than 1.3.3.9 wich i was using
> till yesterday.... so i would like to know wich would be the best
> choice for the moment.
For now, stick with 1.3.3.10svn. If you want to experiment, and I emphasize 'experiment', you are better off with 1.3.5svn, since the broken things in 1.3.4 have only been fixed in 1.3.5svn. This having been said, 1.3.5+ is using qt4 instead of qt3, so you will need to add that before you can compile 1.3.5svn. And finally, as we have said many times, 1.3.4+ can load a file saved with any older version. 1.3.3.10svn or older cannot load a 1.3.4/1.3.5svn file.
atentatmente,
Greg
-- Mon Dec 31 14:37:41 CET 2007
source:
http://lists.scribus.info/pipermail/scribus/2008-January/028267.html
http://lists.scribus.info/pipermail/scribus/2008-January/028266.html
http://lists.scribus.info/pipermail/scribus/2007-December/023392.html
The definition of backward compatibility depends on your source. I tried several and for instance wikipedia seems to contradict itself on this subject.
A technology is said to be backwards (or downwards) compatible if it allows input generated by older technology. -- wikipedia
A data format is said to allow backward compatibility if products designed for the new standard can read older standards or formats. -- wikipedia
source: http://en.wikipedia.org/wiki/Backward_compatibility
The file format has changed and is NOT backwardly compatible. You have been warned. We have specifically disabled the ability to open 1.3.4+ files in the stable 1.3.3.x versions. Our plans for a new file format should be settled in the 1.3.6 -1.3.7 development period. -- Scribus Version 1.3.5 Readme source: http://docs.scribus.net/index.php?lang=en&page=readme
Because of the new file format features, Scribus documents saved in 1.3.5 are *not* backward compatible with 1.3.3.x or 1.2.x . -- CHANGES 1.3.3.x to 1.3.5
Because of the new file format features, Scribus documents saved in 1.3.x are *not* backwardly compatible. -- CHANGES 1.2.x to 1.3.x
source: http://scribus.info/svn/Scribus/trunk/Scribus/README
Q: Is there any file format incompatibilities between scribus 1.2 and scribus 1.3? I have created lots of production documents with scribus 1.2. Is compatibility guaranteed for upcoming versions?
A: Scribus 1.3.x can always load 1.2.x formats. We, in fact, test files from versions as old as 0.5.5. Where there may be differences is some minor settings in the distances from the top of text frames in 1,3.x which has more control over this.
Scribus 1.3.x version files cannot be opened in 1.2.x. -- source: http://www.scribus.net/?q=faq
Scribus seems to use the following definition:
If a newer software version cannot save files that can be read by the older version, it is not backward compatible with the older version, although it may provide an irreversible upgrade capability for the old files. -- wikipedia
Tsoots pointed out on IRC that Scribus is able to open a older datafile in a later version. I asked specifically if 1.3.3.x datafiles could be opened in a later version like 1.3.5 or 1.4/1.5. That should not be a problem I was told.
I suppose it would be handy if this was pointed out more elaborate instead of just using an ambiguous term like "backward compatible".