I use both the 3.02 and 3.1g Windows versions (also MegaPov 0.4).  Isn't a
problem.  The others I have here run under DOS.
The concept is, as people know, that backward compatibility is a matter of
convenience in order to use older scenes or features from older versions without
having to juggle versions.  In fact I'd say the biggest problem isn't about
using older syntax as it would be the using of newer syntax in older versions.
Mix-ups would occur if you had a scene containing old and new together unless
the latest version were to accommodate the change instead.
Dare I ask, what if you wanted to do a media plus halo scene?  But really there
isn't much in the way of what an earlier version did which the later versions
can't do.  Mostly a matter of syntax, aside from the aforementioned 'halo' and
of course 'atmosphere'.  However it seems these two things have been considered
evolutionary dead-ends which should never have existed.  Not thought as such by
many people apparently, but perhaps only due to the using and learning of them
over that short period of time they were a part of POV-Ray.
Back to the point of the question.  It's not a good solution to use older
versions just to keep using older scene files unless the idea is to remain
working on them indefinitely in the same way.  There should be an evolving
taking place whether the Neanderthals of the POV-Ray Trace scripts ultimately
disappear or not.  Still, I like the idea of everything continuing from it's
inception to the next version without any gap.  To say that's feasible though is
another matter left up to programming neatness.

Bob

"Serge LAROCQUE" <sgl### [at] hotmailcom%> wrote in message
news:38d31dc2@news.povray.org...
| Would it be easier to distribute the old binaries instead of keeping the
| new binaries backward compatible? (I am not advocating either option,
| just asking)
|
| So, if you had a 2.0 pov file (or whatever) you could use the binary for
| that version. I can see that this would be easy to do in the unix
| versions, less so for the Win32 versions. (i.e. if you have a 3.0 and a
| 3.1 binary, I don't know how easily you could have both on a windows
| system)
|

Post a reply to this message

Serge LAROCQUE wrote:

> Would it be easier to distribute the old binaries instead of keeping the
> new binaries backward compatible? (I am not advocating either option,
> just asking)

A scene is often constituted of various bits and parts. Some may have been
made specifically for the current scene, others may be derived from previous
scenes, or from pov script produced by utilities. While it's good practice
to convert the old scripts to the newer syntax, it's not always easy or
straightforward. For instance, when Nathan Kopp changed (for the better,
since it fixed an old bug) the implementation of "normals" in Megapov, it
automatically ruined most of the scenes that had normals in it, because you
have to change and test the normal statement of all your previous textures.
So Megapov 0.4 has now a version switch that makes it easier to use
pre-Megapov textures.
The other issue is about utilities. There are a lot of POV related utilities
(macros, include files, binaries), but most are no longer updated and still
output "old" pov syntax. It always take time before such utilities are
replaced by newer ones.

G.

Post a reply to this message

In article <38d31dc2@news.povray.org>, Serge LAROCQUE 
<sgl### [at] hotmailcom%> wrote:

> Would it be easier to distribute the old binaries instead of keeping the
> new binaries backward compatible? (I am not advocating either option,
> just asking)

One of the biggest reasons for keeping backwards compatability is so 
things like include files can still work in current versions without 
having to be converted. You can write a scene in the latest version, and 
include a file that uses the #version command to allow it to parse as an 
older version, and not have to convert the whole include file to the 
latest version. This would be impossible if you use multiple versions.

And while it might be nice to have the older versions officially 
available alongside the new ones(for features like halo and the older 
syntax without interior), I think they would just make support harder.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

Chris Huff wrote:

> And while it might be nice to have the older versions officially
> available alongside the new ones(for features like halo and the older
> syntax without interior), I think they would just make support harder.

Not to mention that older versions have bugs that newer versions were
made to correct. There is good reason to stop supporting older versions
of the program while still providing backward compatibility many of
which have already been explained in the other replies to this thread.

-- 
Ken Tyler -  1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

On top of what the others have said, note that the binary (Windows) is only
about 1.5 meg, and compresses (i.e. for internet/disk transfer) to about
half that - not exactly suffering from bloat.

Post a reply to this message