<br><br><div class="gmail_quote">On 20 October 2011 11:19, Alexandre Prokoudine <span dir="ltr"><<a href="mailto:alexandre.prokoudine@gmail.com">alexandre.prokoudine@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div><div></div><div class="h5">On Thu, Oct 20, 2011 at 12:49 PM, ale rimoldi wrote:<br>
> hi mike,<br>
><br>
>> Some things shifting are unacceptable between revisions.  Do you<br>
>> seriously expect people to redo all their layouts because text<br>
>> placement was implemented "wrong" in previous versions?<br>
><br>
> yep, if they reopen the file i would expect them to check them!<br>
><br>
> the rule: don't update / upgrade during a production run is always valid<br>
> (except if you have very good reasons to update / upgrade... but in<br>
> that case you will probably save much time on other issues!)<br>
><br>
> certainly, i agree with that in the ideal world such changes should not<br>
> happen... but scribus i not perfect, yet :-)<br>
><br>
>> You either<br>
>> have to accept that it will be "wrong" forever due to poor judgement<br>
>> during the original authoring,<br>
><br>
> in my opinion this is the worst option ever!<br>
><br>
> producing world globes should be forbidden, because we have all those<br>
> maps showing a flat earth with dragons around it...<br>
><br>
>> or (more professionally) have RC6<br>
>> compensate for this when opening RC5 (and earlier) documents by<br>
>> automatically correcting the text placements so their IS no shift.<br>
><br>
> this is one of the sources for code bloat and spaghetti code!<br>
><br>
> don't misunderstand me, i'm not against keeping the compatibility, but<br>
> knowing about the spare resources in the hand of the developers<br>
> who are on the release of 1.4, i would not expect them to come<br>
> up with a solution.<br>
><br>
> there are good chances that they finally (or even pretty soon) will<br>
> come up with a solution... but i would not expect it from them.<br>
><br>
> on the other side i wonder if (and how long) we should keep such a fix<br>
> in the code... if one is ever written...<br>
><br>
><br>
>> Either this needs to be corrected promptly, or I'm reverting back to<br>
>> RC5, because I'm CERTAINLY NOT going to manually change all my text<br>
>> frames across multiple documents!<br>
><br>
> if you're working on a specific project and are not ready to fix such<br>
> issues, yes the solution is not to update!<br>
><br>
> as i wrote above, it's a good habit *not* to update while you're working<br>
> on a specific project!<br>
> most of the time there is no risk, but sometimes (like this time) you<br>
> get a version which is broken for you!<br>
><br>
> don't forget that you can have several versions of scribus<br>
> installed in parallel (i would not run two RCs at the same time<br>
> though... it will probably work, but you may have problems beceause they<br>
> access the same preferences file)!<br>
> so, use RC5 for the ongoing project and RC6 for the new ones!<br>
><br>
><br>
> === disgressing ===<br>
><br>
> btw, this is one of the main reasons, why many people don't like the way<br>
> john culleton is keeping his scribus up to date!<br>
> (and why they don't like him to promote the way he is doing it...)<br>
><br>
> updating, compiling and installing scribus overnight is bad because you<br>
> have no control over the code currently installed.<br>
><br>
> if you use scribus in production you should always keep a version you<br>
> know that works for you. and stick to it for your daily work.<br>
> when you have some spare time, install a newer version, test it on new<br>
> projects and only when you know that is working good enough for you<br>
> replace the old one.<br>
><br>
> everything else is dangerous for your health!<br>
><br>
> === end of disgression ===<br>
><br>
> voilà, i hope that a solution for this problem can be found... but if<br>
> it is not, i don't see it as a huge issue... there are workarounds...<br>
<br>
</div></div><not a personal attack><br>
<br>
Bottom-line:<br>
<br>
1. We screwed your projects, but we are a small team, don't expect us<br>
to fix it. Especially since changing the way your document looks is<br>
such a non-issue in professional desktop publishing.<br>
<br>
2. We will probably continue screwing your projects in the future<br>
between minor revisions that are actually supposed to fix things.<br>
That's 'cause of quantum.<br>
<br>
3. We really don't like the way John Culleton works.<br>
<br>
*sigh*<br>
<br>
So what should I tell users? To keep all the possible revisions of<br>
Scribus just to be able to open their files?<br>
<br>
What is the proposed way to figure out which version to use? Save a<br>
text file that will say which version to use?<br>
<br>
Will every revision of Scribus be supported at least few years so that<br>
people can be sure they can run an older version on a new system to<br>
reopen their files and not find themselves knee-deep in mutated<br>
layout?<br>
<br>
Finally, is it possible that the team locks changes to the file format<br>
and fonts rendering for at least a couple of years? The file format<br>
has changed with little backwards compatibility so many times that I<br>
don't feel justified to blame vendors of proprietary software for same<br>
practice anymore.<br>
<br>
</not a personal attack><br><font class="Apple-style-span" color="#888888"><br></font></blockquote><div><br></div><div>Okay, so this is not really the first time this kind of discussion popped up here. And while I can understand the point of view of the developers (Expect proper releases to work right and everything else to change) I have to say that this sucks from an enduser point of view. Why? Because a) the features of new version have always been to cool not to use them (at least for me) and b) even the development version works usually well enough to actually use it. And honestly: The scribus release cycle is ridiculously long. And no, this is not only true for 1.4 but we have had the same discussion with the same arguments for 1.3.4. </div>

<div><br></div><div>And I would attribute most of the problems in this thread to the release model. The whole idea of keeping one stable version and one development version does not seem to work. Because most people seem to be eager to use new features as soon as they can und there is not a really good way with open source software to stop them. And really: Judging by the discussions on the list the release candidates for 1.4 don't seem to be received as release candidates but minor version numbers. And with eight months between rc1 and rc6 I can see why.</div>

<div><br></div><div>I personally would opt for releases with smaller changes way more often. And skip all that we have a development version that we work on for two years and then take another year to stabilize it and then release it and only fix bugs. That is a nice model for huge companies who charge a lot of money for each release. It does not really seem to work for any open source projects.</div>

</div><div><br></div><div>Jan</div>