Gerrit P. Haase wrote:
You wrote:
Why isn't it possible to have a recent download via CVS or snapshots on a daily basis? Why is it that difficult with GPC?
For all I can tell, this would cause even more confusion because such snapshots most of the time are even less stable to unusable. (Especially these years, when we're fixing a lot of fundamental problems which involve bigger changes. Perhaps it will be different a few years from now when things will roll along nicely with small, localized and independent changes, but that's always a nice dream, and I don't know if/when we'll ever get there.)
[...]
That is what CVS is good for, you checkout the source, modify it, test it and make it usable and when all work is done, you check your changes in,
Well, that's just what I do before an alpha release now. As I said, this testing etc. takes some extra time, so I can't do it too often. I.e., with CVS I'd just do a checking every 1-2 months or so, so it would be the same (except for the up-/download method).
I don't need a repository where broken code is archived, it should be possible to build sources from CVS every time one checks it out of course. Unstable code does not belong in a repository.
Agreed. (Unfortunaly, my working code is (more or less) broken most of the time ...)
Adriaan van Os wrote:
Frank Heckenbach wrote:
Also, before a release I run the tests on some other systems (since target-specific bugs are not so rare, unfortunately) -- though for alpha releases I don't necessarily fix all the bugs I find there if they're tricky and uncommon enough --, and run some scripts that prepare the download files, web pages etc.
If it is helpful, I would be pleased to test a soon-to-be-released pre-alpha version on Mac OS X. I guess Maurice Lombardi and Prof A Olowofoyeku would be prepared to do the same on their respective platforms also.
Might be a good idea.
BTW, I do test under DJGPP, though with a cross-built (native DJGPP compiler) GPC and under Linux DosEmu -- occasionally that makes a difference, but usually not too big. That I didn't catch the gcc-3.3 defines problem is just because I didn't test with gcc-3.3 at all before the last release.
Another possibility is to release an alpha version like we do now and then, say three weeks later, a beta version with the necessary fixes of reported problems. However, these are just ideas, I don't want to generate extra work for Frank.
This is a bit extra work, especially when I want to start major changes after an alpha (which I'm doing right now, so for this release, it's too late), but perhaps we should try this after the next release. Since I want to slowly move towards a 2.2 release, we'll need a beta version sometime, anyway.
Perhaps you do the testing on your systems after the alpha release (mostly as you do now), so I won't have to make a pre-alpha, alpha and later beta version, just an alpha and a beta then.
If this works out, I figure we can have some alpha/beta pairs, then a few release candidates and a 2.2 sometime next year.
Frank