Am 01.09.2018 um 04:15 schrieb Kenneth:

> A question, though: In testing out alphas, betas, etc., OR while running the
> original 3.7.0, should I make ONE master POVRAY.INI file and always use that, no
> matter what program version I'm running? Up until now, I've always thought that
> each version should keep its own INI file intact. (Uh, which obviously led to my
> problem!)

The plan is as follows (for Windows at any rate):


(A) Final Releases
==================

Final releases of different "generations" (e.g. v3.7 vs. v3.8) are
intended to live separately from each other without interfering. The
only intentional point of contact would be the new generation copying
settings from the older generation (if detected) when first started.
(This means that, among other things, they each have their own POVRAY.INI.)

Final releases of the same generation (e.g. v3.7.0 vs. v3.7.1, though
this is hypothetical) are intended to replace each other. The only
reasonably sane way for different binaries of the same generation to
live alongside each other would be to rename one of the binaries, and
have both binaries share everything (most notably the POVRAY.INI, but
also registry settings and other stuff.)


(B) Release Candidates
======================

Release candidates are intended to behave exactly like the respective
final release (except for showng a different version number); this
extends to where they choose to live and how to (not) cooperate or
interfere with other versions.


(C) Beta Releases
=================

In order to allow for installing a beta release while also keeping an
earlier final release of the same generation (e.g. v3.7.0 proper and
v3.7.1-beta.1), beta releases are intended to live in their own happy
place, without interfering with any non-beta versions (but replacing or
interfering with other betas of the same generation).


(D) Development (Alpha) Releases
================================

While all of the above come with an installer, alpha releases don't;
therefore, to make installation reasonably easy, they need to piggyback
on an existing installation, and interfere with it extensively. It is
presumed that alpha users are experienced enough not to mess up their
nice final release, and are willing to accept the (small) risk of the
alpha accidently screwing something up.

New alpha releases of an existing generation (e.g. v3.7.1-alpha) will
piggyback on an earlier final release of the same generation (any v3.7
in the example case.

Alpha releases of a brand new generation (e.g. 3.8.0-alpha) have to
piggyback on a final release of the previous generation (again any v3.7
in the example case).


(E) Experimental Releases
=========================

Same deal as with alpha releases.

Post a reply to this message