Re: Sv: TODO

[Christian Reiniger <warewolf@mayn.de>]

Bjarke Hammersholt Roune wrote:

>>All in all it's no more the "we'll unite all the SDKs" and "we'll create a
>>good package of everything" approach but rather a "we try to make it easy
>>for game developers to make informed choices" one.
>>
>I think "getting it all together" is still a good idea. However, I also do
>think that should be kept a bit on the back-burner (is that a word?) for

(back-burner) guess so. At least I already heard it somewhere else.

You're perfectly right. We have to clean up our own mess before we can
start new things.

>>(1) Clean up the CVS repository. (which is a real mess now)
>>
>I think the way you suggest laying out things is fine.

Good. But we should first set up the complete thing locally (ftping or
mailing the tar.gz's around) until we know it's a good layout - before we
even touch CVS.
And some "CVS access guide" (esp. concerning how and when adding
directories to CVS is allowed) could be useful as well.

>>(2) Rewrite the build system (which is a little mess now)
>>
>I don't know anything about that, so I can't comment.

Well, you *do* know ;)
What do we need to make it easy to build the library under Win32? A set of
makefiles, a project file or something else?

>>(3) Clean up the core PPlay headers (which are rather messy now)
>>
>Oh yeah, that reminds me: either each header should only include the
>PenguinPlay.h header, -OR- one of the project-specific headers, since all
>the project-specific headers also include PenguinPlay.h (atleast
>PenguinFile.h does).

Doesn't matter. That's what include guards are for. And including both
PenguinPlay.h and <sublib>.h is IMHO clearer (it's bad behavior to rely on
some header including another one).

>That, or IMHO the project-specific headers should not include PenguinFile.h

PenguinPlay.h?
But usually they need the things declared in there (e.g. data types).

>>(4) Decide on a good versioning scheme (which we don't have at all now)
>>Linux-kernel - like should be good :
>>V x.y.z where
>>x = major version, changing only for really revolutional changes
>>y = minor version, changing for major changes in functionality,
>>    an odd number meaning developmental code and even meaning stable code
>>z = patchlevel
>>
>Sounds good to me. So PenguinFile is actually at version 1.0.0 then? Sounds
>a bit weird, but 0.0.0 is even... -1.0 is even worse.

Well, 0.0.8 or so is more appropriate. For PenguinPlay as such that is.
0.1.0 should be the first usable (alpha) release.
BTW - at least in linux-kernel the even-number-is-stable, odd-is-developer
thing started only after V1.0.0
Before that simply everything is developmental ;)


	Christian
--

Drive A: not responding...Formatting C: instead