> Since most of our games are references by their "Alpha" number anyhow, > I think the numbering scheme may work. However, I highly recommend > that in official numbers, we don't do say just 21, instead, make it > 0.21. All versions our previous versions like 0.8.21 and 0.8.20, have > this 8 that doesn't carry any meaning, so take it out. After 1.0, we > will want to keep a similar scheme, 1.1, then 1.2, then 1.3, 1.4, 1.5, > 1.6, 1.7, 1.8, 1.9, 1.10, 1.11 .... 1.42 and so on.
The numbering scheme seems to be a matter of believes ... I think only debian cares about the alpha keyword. And only our *.deb files are called alpha. I think 0.9 would be more consistent than 0.21 . >> Complete rewrite sounds harsh. I'd assume you can exchange autotools >> without having to dig deep into glob2 code. > > Yes, and I have. I got scons to compile compile glob 2 code no problem > in less than 30 minutes. Scons is my builder of choice because its > extremely flexible. Since Scons files are python scripts, anything > Scons can't do, you can implement with very minimal effort. And scons > is also very flexible. Hey, have a look: SCons 0.96.95 (candidate for 0.97) ... Now, we know the meaning of .8. in our version numbering. I have googled to compare scons and cmake. And scons was the definite looser. - portability issues on non-unix systems. - slow development - KDE really wanted to use this, but gave up. Now they use cmake. http://lwn.net/Articles/188693/ http://swik.net/SCons+cmake But I didn't spend much time on this research. Just looked into the scons Changelog: latest stable release: RELEASE 0.96.1 - Mon, 23 Aug 2004 12:55:50 +0000 http://www.scons.org/CHANGES.txt Another system would be bjam which is used and written by the boost developers. -- Kai Antweiler _______________________________________________ glob2-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/glob2-devel
