Am 12.06.2021 um 14:08 schrieb Le_Forgeron:

> Did I understood correctly:
> 
> 1. latest, official, stable version is head of "latest-stable", and it
> is 3.7.0.9 so far

Yes.

> 2. current development of 3.8.0 is head of "release/v3.8.0"

Yes.

> 3. "master" is to be ignored (so far ? for ever ?), but derivative works
> should not hurry to switch to something else (i.e. I won't move a line
> of code for the time being)

That depends.

We're not currently sure how to proceed regarding the master branch, but 
two things can probably be taken for granted:

- The `master` branch will ALWAYS be the one into which all feature 
development will eventually merge into.

- The `master` branch will NEVER be the one in which any stable release 
will be finalized. That work will always be done on branches.


Therefore, if your derivative work is a fluid thing anyway, with little 
in the way of "stable versions" planned in the foreseeable future, then 
you might not want to worry about POV-Ray v3.8.0 anyway, and instread 
continue to use the `master` branch as your basis throughout.

If instead you want your derivatvie work to be based on well-defined 
version of POV-Ray, then you have essentially two options:


(A) Match the POV-Ray release cycle in your derivative work; that is, 
use the release of a stable version of POV-Ray proper as an opportunity 
to also define a stable version of your derivative work, but between 
such versions just "flow" with the ongoing development of POV-Ray. 
Especially for derivative works that focus on providing an alternative 
user interface I guess this is the smartest approach.

In that case, you'll probably want to keep the work've recently done on 
the `master` branch, to later get back to that as your derivative's main 
line, but also branch off and follow the v3.8.0 rollback for your 
derivative work's next stable release.


(B) Always base your derivative work on stable versions ov POV-Ray, 
porting it to newer versions of POV-Ray only every once in a blue moon 
as they are officially released.

In that case, you can possibly ignore `master` entirely, and just "hop" 
between those rare stable versions. It would be some tough integration 
work though whenever you port your work to a new version.


> 4. testing & bug investigations in github issues should be between 1 & 2
> (1 for base, 2 for detection of regression, 2+ for a fix)

Well, that depends entirely. In some cases, it may still be entirely 
reasonable to even compare with v3.6. And once v3.8.0 has seen its first 
repease proper, enters maintenance, and v4.0 development picks up, focus 
of testing would shift again.

v3.8.0 is heading towards beta testing phase, so that's where we're 
focusing our testing and issue reporting attention to, and in that 
respect the references should indeed be v3.7.0 on one side, and any 
earlier v3.8.0 betas on the other.

For the first beta, it migh make sense to compare with 
v3.8.0-alpha.9945627. Any later v3.8.0-alpha versions should be disregarded.


I hope this answers more questions than it raises new ones.

Post a reply to this message