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 220.127.116.11 so far
> 2. current development of 3.8.0 is head of "release/v3.8.0"
> 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)
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