Am 16.06.2021 um 20:14 schrieb ingo:
> When I move I put dates on boxes. Boxes that have not been opened are
> thrown out unopnend after two years unless they have a red sticker.

So, following that logic, should we just throw away all the sample 
scenes altogether? ;)


> Thinking about this and backwards compatibilty, would it be easier to keep
> a few startegic versions of POV-Ray running, executing, compiling for
> current and future compilers and OS's (3.1g, 3.5, 3.7)? This could give a
> dev more freedom to break things and probably to keep the source cleaner?
> It would also kind of solve the old image problem.

For a purely command-line only thingumajig - no graphical output 
whatsoever - that might be feasible. But porting a graphical user 
interface between different OS versions, different operating systems, 
hardware platforms etc. over and over again... that will almost 
inevitably lead to feature rot, as features not easily portable and not 
strictly necessary will be "temporarily" disabled, others not necessary 
on a particular platform will be amputated and not revived when ported 
to a platform that might benefit from it, and so on...

In the end, the UI versions of the old pieces of software will become 
unusable hunks of rotted code, that aren't worthy of keeping alive.

And then some day command-line interfaces may go out of fashion 
entirely, and the command-line-only strain of the software will suffer 
the same fate, too.


Also, each time the programming language standards change, the old code 
will have to be adapted to work with the new standard. Same deal there: 
Code that was originally clean and sane becomes patched up only at the 
edges that openly exhibit issues, while other portions may be forgotten 
and quietly slip out of alignment, until some day the whole thing comes 
crashing down, because at its core, hidden under layers of patches, its 
bones have become brittle. And the libraries our code relies on will 
also be moving targets, which will break stuff every now and then. Which 
is especially problematic when it's something we're using as extensively 
as the boost thread library.


At some point in time, it will probably be easier to just install an 
emulator or virtual machine, and run old binaries that way.


We've been doing something along those lines with POV-Ray v3.7, at least 
as far as the Unix version goes - putting out maintenance releases to 
keep it compatible with whatever comes our way. But we won't be able to 
keep it supported forever, especially on the Windows platform. We'd 
eventually need to write a brand new front-end for it. Which takes time 
and energy, because the front-end interface differs from that of v3.8. 
And eventually v3.7 will succumb to boost rot, because newer versions of 
boost will grow more and more incompatibilities with our code, and 
eventually cease to even support what we're using it for, because that 
portion of boost is effectively outdated already; while the older 
versions of boost will grow more and more incompatibilities with modern 
compilers, and be unavailable for more and more modern target platforms. 
And ripping out boost and replacing it with something else may turn out 
to be more work than it's worth, due to how intensively we were using it 
in v3.7. At that point, v3.7 will go the way of the Dodo.

The good news is that v3.8 will be reasonably close to v3.7 in its 
behavior, and hopefully work as a plug-in replacement. And work for 
ripping out boost (the most extensively used portions anyway) had almost 
finished in v3.8 (in fact it had, but we're reverting back to before 
that for v3.8.0), so it'll be much less susceptible to poorly aging 
libraries, and thus might be a lot easier to keep alive in the long run 
than poor old v3.7.

In fact, it might even be easier to revive any of the older versions 
than to keep v3.7 alive. v3.6.2 and earlier versions didn't use boost at 
all. Of course they also didn't support multithreading.


Well, so much for my crystal ball peek into the future, anyway. Only 
time will tell how much I'm over- or underestimating the troubles involved.


> Dreaming, maybe a future povray parser could just start an other engine
> depending on the #version of the scene file.
> 
> (I have no idea of the complexity of all that)

That won't fly at all. At best, the combo of parser and render engine 
could be exchanged. But even that would require a well-defined interface 
to plug those pieces into a front-end. We don't have such a thing at 
present, and I dare say we never will. Not a stable one, at any rate. 
Which defies the whole idea. Oddly enough, we'll probably continue trying.

Well, actually we currently have _two_ such interfaces: The POVMS 
interface and the VFE. Neither is anywhere close to intuitive though (at 
least *I* haven't gotten a good grasp on either of them yet, and it's 
not like I'm totally new to the source code), and I wouldn't want to 
have to interface to either of them. And neither seems to be 
particularly suited to just exchanging the back-end on the fly.


> Is there anything of a time frame, weeks, months, less than a year and a
> halve? Currently my time is limited but it will change towards the end of
> the year.

Folks at dev team level are itching to get v3.8.0 out as soon as quality 
concerns permit. I'm pretty sure we'll have the first beta before the 
month is over. How quickly things progress from then on depends; my 
estimates vary between anything from another month (when I'm feeling 
excessively optimistic) to half a year (when I'm extrapolating from past 
frustration). It certainly won't take as long as the v3.7.0 beta phase.

Post a reply to this message