World: r3wp

Good, then you can enjoy the benefit of their testing when the host 
kit release comes out. Less hassle for you.

Fewer testers for you.

A host kit release has more code than a core release. Why would we 
delay a core release until the non-core host kit code is adapted? 
We don't have to wait to release everything at once, when we can 
get the core release out early to testers. This is especially important 
for releases that focus on core changes.

If the binary-only releases where built from the same codebase, the 
code _would_ already be adapted.

And this is the biggest core change in the last year. It needs extra 
testing.

The host kit uses the same code base, but it uses extra code that 
core doesn't. Code that we haven't adapted yet.

speaking for myself...  all of my concerns wrt A108 *are* the changes 
in the core wrt how they affect extensions.


The fact that R3 itself is better is cool, but doesn't really allow 
me to test anything if I can't actually compile the host-kit against 
it.


though I know how preparing working releases takes time, so I'm probably 
a bit more patient than Andreas.  ;-)


I will be starting work on my Custom Gob Renderering A107 R3 host-kit 
sometime this week.  

I still have to *complete* the rendering pipeline architecture from 
end to end (even if its currently very shallow), which is about 80% 
done.

most of what is left is the easy part (the actual OpenGL handling 
itself)

BrianH, that last statement is nonsensical.

Either the binary-only releases are built from the same codebase, 
or they are not.

Let me make it more plain.

I meant to say that I was starting work on the *release* itself (preping 
and cleanup folders of bogus files, and basically uprooting the current 
compilation setup into new clean folders, while doing a little bit 
of diffing on the released A107 to see if any oddities have crept 
in the code.

If the binary-only is a binary built from the hostkit sources with 
the only difference that the r3 libs are statically linked instead 
of dynamically, that is the same code base.

Not *all* of the codebase in a hostkit is used in a binary-only release. 
There is *more* code in a hostkit.

Like?

Graphics.

Optional in the hostkit.

But still needs to be compatible before a host kit release.

Nope. See the Linux hostkits.

(Besides, I got the impression from the R3 GUI team that they have 
A108 pre-releases with graphics enabled. Might have read a bit too 
much between the lines, though.)

You might be too pessimistic when you say that the host kit will 
come out much later. There is nothing to indicate this.

The header changes in A108 will be ignored by A107, and the old settings 
will be ignored by A108, so if you want to have transitional code 
you can use both. The only change that I know is not automatically 
adjusted for is the isolate: true header, so if you need that and 
want it to also be compatible with A108 then also include options: 
[isolate]. And you don't need to use type: 'extension anymore, type: 
'module will do (in either version). Don't use the word 'hidden in 
your modules though, at least not at the top level - hidden will 
be a new keyword in module code, like export.

Except for the 7 month hiatus between the first hostkit release and 
the second.

The situation is different now, and has been for the last 10 releases 
at least.

That may well be. But there's nothing to indicate this.

Except the history of the R3 releases since RMA took over the R3-GUI 
project.

Wouldn't it be faster to give it to Andreas instead of explaining 
why it's not possible? :)

One would think :)

No, as I explained above. Core changes take time to propagate to 
the code surrounding it.

Which, as I explained above, only prevents hostkit releases if RT 
binaries are not built from the same codebase.

And my time is free now. I work on the core, not really the host 
kit much yet. However, I must run an errand. Later :)

Right, the RT core binaries are built from a *subset* of the same 
codebase. As I explained before.

Still not preventing hostkit releases, unless the subset is really 
not a strict subset.

No, but it does explain why it is possible to get a core release 
done first. What you are asking for is to *delay* the core release 
until the rest of the hostkit has been updated.

Nope, if you can do a core release from the same codebase, you can 
do a hostkit release.

Heck, then you could even get external help adapting the graphics 
parts!

Andreas, RMA team doesn't have the A108 hostkit as well so no worries 
;)

Ah, that indeed gives me hope that we'll get the hostkit rather sooner 
than later :)

host-kit: (core) + non-core-parts

So far the core part is at release level. Despite your protests, 
we aren't going to delay the core release until the rest of that 
equation is done.

core = apples + peas

See, I can make up nice equations as well.

But you sure can tell me which part of the Linux hostkit is non-core.

Sorry, english clearly wasn't being understood so I tried to translate 
to a language I know that you are fluent in, REBOL.

Brian, it's easy.

The paren was the important part.

The binaries are not built from the same code base. Simple as that.

There's tons of Carl internal magic sauce.

And obviously it takes some time for him to disentangle that from 
what is externally released, along with some copy/pasting and what 
not.

A subset. [[core] rest-of-hostkit]. We can test the core first, even 
if they are built from the same overall codebase. The core doesn't 
include any code that is not in the hostkit, but the converse is 
not true.

So a core-only hostkit release should be trivial, no?

Nope. Internal testing has to pass before any release. And the subset 
of code that I know that has passed internal testing is the subset 
used by the core binary. Even a core hostkit release has more code 
to test than a core binary release.