Hey! "Neil Jerram" <[EMAIL PROTECTED]> writes:
> For me, almost all of my time since becoming a maintainer has been > absorbed by working on bug fixes, largely to do with slightly odd > platforms (e.g. Mac) or architectures (e.g. ia64). IMO it was > worthwhile to focus on such bug reports soon after they were reported, > because (i) the reporters are still around and interested enough to be > able to provide more info and test fixes, (ii) I believe that running > on more platforms will be good for the Guile community, and for Guile > applications. Same here. But everyone is welcome to help fix bugs! :-) > Basically, my feeling is that Guile users have been badly burned by > major release incompatibilities in the past, and I really don't want > that to happen again. Therefore my "straw man" plan is that > > - we stay on 1.8.x for a while Which IMO means fixing portability bugs and the likes. > - we treat "master" as a pot of goodies, which we aim incrementally to > merge across and release as part of the 1.8.x series The problem is that some of them might be subtly incompatible, mostly because a lot of internals have been exposed and actually used. I think it's good to have API and possibly ABI-compatibility within a major release, so that "1.8.x" really means something, for any value of `x'; requiring "x >= something" is acceptable IMO (we already have this, e.g., with modules that got added in 1.8), but "a <= x <= b" isn't. > - we don't do a big jump to 1.10.x, by just deciding to do so at some > time (+ a bit of pretesting), because I don't feel confident that we > can properly consider and document all of the 1.8 .. 1.10 > compatibility issues at once. I agree that we should reduce the gap between any two major releases. > But #1 : as I said above, I'm pretty sure Ludovic disagrees with this! It's not all black & white. ;-) > I believe that programmers' natural tendency is to plan for infinite > compatibility. +1. (That is especially true in Guile land where many projects are small and developed only on people's spare time, whom you can't expect to dedicate time switching APIs.) > There you're right. We can and should rip GH out now. Actually that > might make an excellent first example for documenting incompatibility. > (Anyone who really still needs it can take on the burden of > maintaining the GH layer themselves.) IMO, if it doesn't cost anything to keep it (beside `.so' size), let's keep it. Thanks, Ludo'.
