Re: Guile release planning
Hi Neil! "Neil Jerram" <[EMAIL PROTECTED]> writes: > OK, it's clear the consensus on 1.8.x is against my suggestion, so > I'll accept that. And I can understand the reasons too. I think > perhaps it comes down to Ludovic's point about the version number > being a hint - i.e. people already have expectations about what should > be in the change from 1.8.x to 1.8.x+1, and mostly those expectations > seem to be API and ABI compatibility, so it makes sense to comply with > that. Yep, it's just a matter of labeling, really. > For 1.10.0, then, we just need to check that there isn't anything in > master that isn't ready/working; if there is, it should be moved into > a branch. In a similar vein, some of the things developed in the 1.7 series, like futures, were never stabilized and are simply commented out for now. Thread support is also somewhat sloppy, as shown my recent reports (e.g., parallel memoization). We need to think about these as well. > And from here on we should adopt the rule that new features > are always developed on branches, and only merged into master when > ready and working. Then we should be able to release master as a new > 1.y+2.0 whenever we see that enough new features have accumulated. > > How does that sound? Sounds good to me! Thanks, Ludo'.
Re: Guile release planning
2008/11/18 Ludovic Courtès <[EMAIL PROTECTED]>: > Hi, > > Andy Wingo <[EMAIL PROTECTED]> writes: > >> Beating a dead horse, 1.8.5 should be compatible with 1.8.3, via >> whatever mechanism. (The actual problem in this case was elsewhere.) > > 1.8.5 *is* compatible with 1.8.x. > >> I am skeptical of pushing significant changes into stable branches. I >> really don't want to be in the situation in which 1.8.4 works for >> someone, but 1.8.7 does not. You might be right, Neil, about that path, >> but it does not give me warm fuzzy feelings. > > Same for me, but we can surely find a reasonable trade-off. Many thanks everyone for your replies to this thread, and sorry for my delay in following up. OK, it's clear the consensus on 1.8.x is against my suggestion, so I'll accept that. And I can understand the reasons too. I think perhaps it comes down to Ludovic's point about the version number being a hint - i.e. people already have expectations about what should be in the change from 1.8.x to 1.8.x+1, and mostly those expectations seem to be API and ABI compatibility, so it makes sense to comply with that. One of my background concerns, when suggesting that we try to get more into 1.8.x, was that if we have lots of release branches (e.g. 1.6.x, 1.8.x and 1.10.x) in use at the same time, we have to do more work to apply fixes to all branches. But in fact that is a lot easier now that we use Git, so probably isn't a big worry. For new features, then, the question becomes: what is our general plan, from here on, for going from 1.y.x to 1.y+2.0 ? As Greg has said, we need to get new stuff out quicker than we have done in the past. Right now we have an growing pile of new stuff in Git, should _all_ of that go into 1.10? I guess the answer is that 1.10.0 - and more generally any new 1.y+2.0 - should include everything that we have which - we believe is ready, i.e. in a sufficiently final form that its API/ABI is unlikely to be broken in future - is working. For 1.10.0, then, we just need to check that there isn't anything in master that isn't ready/working; if there is, it should be moved into a branch. And from here on we should adopt the rule that new features are always developed on branches, and only merged into master when ready and working. Then we should be able to release master as a new 1.y+2.0 whenever we see that enough new features have accumulated. How does that sound? Neil
Re: Guile release planning
Hi, Andy Wingo <[EMAIL PROTECTED]> writes: > Beating a dead horse, 1.8.5 should be compatible with 1.8.3, via > whatever mechanism. (The actual problem in this case was elsewhere.) 1.8.5 *is* compatible with 1.8.x. > I am skeptical of pushing significant changes into stable branches. I > really don't want to be in the situation in which 1.8.4 works for > someone, but 1.8.7 does not. You might be right, Neil, about that path, > but it does not give me warm fuzzy feelings. Same for me, but we can surely find a reasonable trade-off. Thanks, Ludo'.
Re: Guile release planning
Hi, On Mon 17 Nov 2008 00:33, [EMAIL PROTECTED] (Ludovic Courtès) writes: >> And I assume the actually loaded libguile was version 1.8.5? So there >> should have been something in the library saying that it needed 1.8.3, >> which would have caused the link to fail. Does the libtool scheme >> cover this; I'm afraid I just don't know. > > Yes it does (at the level of "supported interface numbers", not at the > level of version numbers, though) Beating a dead horse, 1.8.5 should be compatible with 1.8.3, via whatever mechanism. (The actual problem in this case was elsewhere.) I am skeptical of pushing significant changes into stable branches. I really don't want to be in the situation in which 1.8.4 works for someone, but 1.8.7 does not. You might be right, Neil, about that path, but it does not give me warm fuzzy feelings. Andy -- http://wingolog.org/
Re: Guile release planning
Hello! "Neil Jerram" <[EMAIL PROTECTED]> writes: > But this isn't obvious to me. _If_ the libtool versioning system > works in practice, in the senses of > > - permitting linking when it ought to be permitted > > - failing linking when it ought to fail It partly fails for the second point. Examples: changing the number/type of arguments of a function, changing the layout of a public structure, changing the implementation of public macros, etc. It really requires special care to check whether a change is breaking ABI compatibility. > then it seems to me that a reasonable division of labour is for us > (upstream) to take care of API compatibility, and ensuring that the > libtool numbers are a correct description of ABI state, and for > distributions/users to take care of any consequences of mismatched > libtool numbers. I consider ABI compatibility as important, too, because people don't want to recompile everything every time a minor release is out. Like Andy said, we should guarantee it within a given series, e.g., 1.8.x. After all, the version number is just a label giving users a hint about the type of changes introduced in a version and level of compatibility provided. It's common for free software libraries to remain ABI-compatible within a major series (first and second digits unchanged), to change to the second digit when ABI breaks, and possibly the first digit when API breaks *or* important changes are introduced. >> This is very convenient for binary distributions like >> Debian, and for users in general. > > Are you sure about that? Yes. Even for the few Guile C libraries I develop myself, it's boring to recompile them when switching from 1.8 to 1.9 or one of the other branches. For a distribution, it means burning a lot of CPU power. >> I think enhancements like the lazy symbol binding in modules >> could have been in theory added in 1.8.x since it breaks neither the API >> nor the ABI. > > Agreed; and I think they still can be added in 1.8.x. Yes, but one con could be that it introduces changes that could be visible to users that access Guile's undocumented module-fiddling API. > Yes, but it's an addition. As far as I understand, it's completely > back-compatible, so I would be perfectly happy to feed this in to > 1.8.x at some point. >From a marketing viewpoint, the VM deserves a new version number. :-) In practice, it also requires users to adapt their build system to take advantage of it. > Of course, we should take care that we are 99% happy with the new APIs > before releasing them, as it wouldn't be good to make lots of changes > later. But that's no different from the first public release of > anything - in my view, it should work much better for us to come to > this determination feature-by-feature, than to say arbitrarily at some > point "everything in master" is now ready. I agree that a feature-by-feature approach would be more reasonable. My impression, gathered since the time when Kevin was still with us, was that the goal was zero-breakage within a stable series, such that 1.8.x+1 would always be more portable and reliable that 1.8.x. This approach rules out things like the lazy duplicate symbol resolution, and `libguile-i18n'. Surely we could find an "in-between". > Not necessarily, in my view. We have an extensive test suite, and I > think we can have some confidence in that. After sufficient testing, > I would see no problem with your proposed BDW-GC changes going into a > 1.8.x release. The BDW-GC change is ABI-incompatible, it introduces a new dependency, augments the API and potentially introduces subtle changes in behavior, so I would definitely change the version number for that. Again, that version number is just a hint for users. >> BTW, we need to consider releasing 1.8.6 one of these days! ;-) > > Yes. Do we have any particular more things to get into this? (I > don't think I have anything.) I'm interested in the scm_c_read issue I raised on the list, and Linas is interested in threading issues. The former seems more important to me (eh eh ;-)) because it introduces a regression. Then, I don't think we have to solve every single bug right now, it's already been too long since 1.8.5. Thanks, Ludo'.
Re: Guile release planning
Hello, "Neil Jerram" <[EMAIL PROTECTED]> writes: > And I assume the actually loaded libguile was version 1.8.5? So there > should have been something in the library saying that it needed 1.8.3, > which would have caused the link to fail. Does the libtool scheme > cover this; I'm afraid I just don't know. Yes it does (at the level of "supported interface numbers", not at the level of version numbers, though), provided the person who prepares the release correctly updates the Libtool version info---which has always been the case, of course. :-) Ludo'.
Re: Guile release planning
"Neil Jerram" <[EMAIL PROTECTED]> writes: >> 2008/11/11 Ludovic Courtès <[EMAIL PROTECTED]>: > But this isn't obvious to me. _If_ the libtool versioning system > works in practice, in the senses of > > - permitting linking when it ought to be permitted > > - failing linking when it ought to fail > > - providing a clear error message in the failure cases, so that the > user knows what to do next Except for 'clear error message', I think shared library linking (in ELF at least) satisfies that. > then it seems to me that a reasonable division of labour is for us > (upstream) to take care of API compatibility, and ensuring that the > libtool numbers are a correct description of ABI state, and for > distributions/users to take care of any consequences of mismatched > libtool numbers. That is the standard model, and I think it's fine, modulo the frequency of ABI breaks (and thus shlib major version increases). ABI is not just shared library versions - it's all the scheme-level interfaces that a guile-using program might call. > I think the latter "consequences" are just having to recompile > something against the new libguile version. For a user who has > already decided to use the source code version of an application, that > should be trivial; for distributions, that's just what they do all the > time, isn't it? Yes, except that it's a pain if it happens often, and it more or less constrains all the guile-using components in a system that aren't leaves to use the same guile version. > Are there other consequences that I'm missing? Frequent API and ABI breaks are in my view a sign of an immature development process, and a warning not to rely on something. guile aims to be a scripting language to be added to various programs, so we should hav as a major goal being stable enough to be relied on. > Sure, we could also take on ABI compatibility ourselves, but I think > that overconstrains our development, and/or makes it harder. I think that we should aim to have infrequent ABI breaks. Every year or so is probably ok. >> I think enhancements like the lazy symbol binding in modules >> could have been in theory added in 1.8.x since it breaks neither the API >> nor the ABI. > > Agreed; and I think they still can be added in 1.8.x. Sure - this is totally fine. Programs that worked against 1.8.x, both compile time and run time, will still work against 1.8.x+1. But, the reason we want to add to 1.8 is that 1.10 wasn't release 18 months ago, about which I'll rant more later. >> A GC change, or a rewrite of the string/char code with >> Unicode support would be a big jump, too. Such big jumps surely need a >> new major release. > > Not necessarily, in my view. We have an extensive test suite, and I > think we can have some confidence in that. After sufficient testing, > I would see no problem with your proposed BDW-GC changes going into a > 1.8.x release. > > Same for Unicode support - if the API stayed compatible. If the API > could not be compatible, then I would agree that we might need a new > major release. The biggest issue is API breaks without adequate warning. To remove something from the API, it should be marked deprecated in a stable release, and then have probably 2 years pass during which all depending programs to update and release. The key is that one has to be able to say in good conscience that those depending programs are lame or unmaintained if they didn't update. If API breaks other than via the above rules happen too often, then guile really should support (natively) the installation of multiple vesrions at once. pkgsrc has "guile" which is 1.8.x and "guile16", and guile16 installs to /usr/pkg/guile/1.6 as prefix instead of /usr/pkg. guile simply doesn't have the mindshare to support this kind of complexity. An example of API problems is Linux itself. I am working on a project using the kernel and going from 2.6.20 to 2.6.24 is a huge change that seems to have significant API breaks (for kernel modules). If these changes are as bad as they seem, this just isn't adult software engineering and I would have to recommend against relying on such code. I think guile's real problem has been that while people hack on head, this hacking doesn't seem to have the clear goal of producing a stable release. Of course all the hard-core guile hackers run guile from (choose-VCS-weekly :-), but programs that depend on guile should not -- they need to depend on versions which are packaged. So my general rule for software is that as soon as people say "you should run HEAD instead of RELEASE, it's better", a release from head is overdue. So I don't think there's anything wrong with the hack-on-head-cut-stable-branches-periodically approach, except: 1) try really hard to avoid API breaks, and take the ugliness of new function names with the new semantics/signatures as a lesser pain 2) release a new stable version from head every year or so. For 2, I suggest calling feature freez
Re: Guile release planning
2008/11/15 Neil Jerram <[EMAIL PROTECTED]>: > 2008/11/11 Ludovic Courtès <[EMAIL PROTECTED]>: >> BTW, we need to consider releasing 1.8.6 one of these days! ;-) > > Yes. Do we have any particular more things to get into this? (I > don't think I have anything.) I'm seeing frequent and wide-spread deadlocking in the thread-enabled version of guile. I'm debugging this, but do not yet have a patch. I sure would like to see this fixed in 1.8.6, and am laboring under the optimistic assumption that I can find a patch in a few days, and that there won't be yet another problem that shows up after that. --linas
Re: Guile release planning
2008/11/11 Ludovic Courtès <[EMAIL PROTECTED]>: > > Your note doesn't take binary compatibility into account, and I think > it's an important thing, too. I think the ideal is to maintain binary > compatibility within a major series, as we've done (or tried to do) in > the 1.8.x series. (And Andy wrote "I think it needs to be guaranteed.") But this isn't obvious to me. _If_ the libtool versioning system works in practice, in the senses of - permitting linking when it ought to be permitted - failing linking when it ought to fail - providing a clear error message in the failure cases, so that the user knows what to do next then it seems to me that a reasonable division of labour is for us (upstream) to take care of API compatibility, and ensuring that the libtool numbers are a correct description of ABI state, and for distributions/users to take care of any consequences of mismatched libtool numbers. I think the latter "consequences" are just having to recompile something against the new libguile version. For a user who has already decided to use the source code version of an application, that should be trivial; for distributions, that's just what they do all the time, isn't it? Are there other consequences that I'm missing? Sure, we could also take on ABI compatibility ourselves, but I think that overconstrains our development, and/or makes it harder. > This is very convenient for binary distributions like > Debian, and for users in general. Are you sure about that? I would expect Debian already to have completely automatic ways of coping with this kind of thing (i.e. libtool numbers changing). And I've described what I think the impact on users is above; seems quite small to me. > I think enhancements like the lazy symbol binding in modules > could have been in theory added in 1.8.x since it breaks neither the API > nor the ABI. Agreed; and I think they still can be added in 1.8.x. > Things like `libguile-i18n' could have been added too, but > the issue when adding C code is portability: it may be that this module > would have caused build issues on some platforms. Now, with more > frequent releases, it would be reasonable to hope that such regressions > would quickly be fixed. Agreed, I think we can handle this. > Another thing is actual big jumps. I think the addition of the VM is a > big jump. Yes, but it's an addition. As far as I understand, it's completely back-compatible, so I would be perfectly happy to feed this in to 1.8.x at some point. Of course, we should take care that we are 99% happy with the new APIs before releasing them, as it wouldn't be good to make lots of changes later. But that's no different from the first public release of anything - in my view, it should work much better for us to come to this determination feature-by-feature, than to say arbitrarily at some point "everything in master" is now ready. > A GC change, or a rewrite of the string/char code with > Unicode support would be a big jump, too. Such big jumps surely need a > new major release. Not necessarily, in my view. We have an extensive test suite, and I think we can have some confidence in that. After sufficient testing, I would see no problem with your proposed BDW-GC changes going into a 1.8.x release. Same for Unicode support - if the API stayed compatible. If the API could not be compatible, then I would agree that we might need a new major release. > BTW, we need to consider releasing 1.8.6 one of these days! ;-) Yes. Do we have any particular more things to get into this? (I don't think I have anything.) Neil
Re: Guile release planning
> From: Neil Jerram <[EMAIL PROTECTED]> > Hi Mike, thanks for your response. > > I would propose, then, that we clearly flag (on the mailing list) an > API change at the time when the relevant commit is made to the > repository, and make sure that some minimum period of time elapses > before the subsequent release. I would hope that you could then work > on the basis of the commit, without needing a formal pre-release. > (Any kind of release takes a bit of time, and pre-releases might > confuse the overall release picture.) > > Would that work? Works for me.
Re: Guile release planning
2008/11/11 Linas Vepstas <[EMAIL PROTECTED]>: > > Any ideas for binary compatibility for the "micro" revisions? At our "upstream" level (i.e. not trying to solve all of the distribution-level issues), I think the theory is that this is covered by library interface numbering. In other words, if a change in guile causes the new libguile not to be compatible with the previous one, libguile's revision number should be incremented. > I recently discovered that a library compiled against 1.8.3 > would core dump when used with an application compiled > against 1.8.5. And I assume the actually loaded libguile was version 1.8.5? So there should have been something in the library saying that it needed 1.8.3, which would have caused the link to fail. Does the libtool scheme cover this; I'm afraid I just don't know. > The linux kernel got rid of the stable/unstable branch idea, > and it's worked really really well. (the reasons why are > widely documented) I'm for it. Yes, I guess my suggestion is quite similar to what the kernel did. Thanks, Neil
Re: Guile release planning
Hi Mike, thanks for your response. 2008/11/11 Mike Gran <[EMAIL PROTECTED]>: > If the base Guile C API remains stable, it doesn't matter to me how the > releases occur, because they won't break my libraries or projects. OK. > If the Guile C API needs to change, some sort of notification and beta > pre-release would be preferred, so that I can test my projects before the new > Guile gets yum'ed out to my group. How exactly would a "beta pre-release" help? It seems you have in mind people who are building your project from source, using a distro-updated libguile. Even with notification/pre-release, and with you having updated your code accordingly, one of your users might not have downloaded your updated code. I guess I can see, though, that it's nice if you have a bit of notice, and hence time to prepare an update. And then I can also see that to do that you will want real code to work with, not just an English description of the API change. I would propose, then, that we clearly flag (on the mailing list) an API change at the time when the relevant commit is made to the repository, and make sure that some minimum period of time elapses before the subsequent release. I would hope that you could then work on the basis of the commit, without needing a formal pre-release. (Any kind of release takes a bit of time, and pre-releases might confuse the overall release picture.) Would that work? Neil
Re: Guile release planning
Hi Han-Wen, On Wed 12 Nov 2008 05:41, Han-Wen Nienhuys <[EMAIL PROTECTED]> writes: > One angle that we could take is time based release planning, like GNOME and > Fedora do: plan to do one or two releases per year on a rigid > schedule. With GNOME there is also a difference, as you know: they do not add API in micro series, only in minor series, and never change the API or ABI in incompatible ways. While that should be our intent, it's quite a burden for a language implementation that exposes as much of its guts as Guile does. I think we should preserve Guile's ability to change API or ABI incompatibly (while providing shims: next mail). Releasing more often would be great, though. Andy -- http://wingolog.org/
Re: Guile release planning
Neil Jerram escreveu: > So, what do you think? There have been discussions of release > strategy in the past, which I've seen as 50/50 between the split > stable and development model (which we have now) and the steady new > feature model (described above), but I don't recall them considering > the overall community focus angle before. In my view, when we add in > that angle, the steady new feature model is better. One angle that we could take is time based release planning, like GNOME and Fedora do: plan to do one or two releases per year on a rigid schedule. The LilyPond 2.11 vs. 2.12 jump has been delaying for too long, but I generally do a biweekly release, which is stable enough to reasonably be called 'stable', and it has worked very well so far. The precondition for this is that there is a good test-suite so we can be sure that a release that passes the tests is good. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
Re: Guile release planning
Hi, On Tue 11 Nov 2008 22:05, "Linas Vepstas" <[EMAIL PROTECTED]> writes: > 2008/11/11 Andy Wingo <[EMAIL PROTECTED]>: >> --enable-threads, or vice versa. Probably what happened to you? > > Don't think so. The 1.8.3 was from Ubuntu Hardy. I assume > it had threads turned on Nope, Debian builds --without-threads. > The 1.8.5 was self-built. I did not specify --enable-threads, this > seemed to be on automatically. Voilà. Andy -- http://wingolog.org/
Re: Guile release planning
Quoth "Neil Jerram" <[EMAIL PROTECTED]>: > In my view, when we add in [the community focus] angle, the steady new > feature model is better. As a non-developer, but committed user, I couldn't agree more. Sebastian
Re: Guile release planning
2008/11/11 Andy Wingo <[EMAIL PROTECTED]>: >> Any ideas for binary compatibility for the "micro" revisions? > > I think it needs to be guaranteed. > >> I recently discovered that a library compiled against 1.8.3 >> would core dump when used with an application compiled >> against 1.8.5. Ludovic asked: > Do you remember what caused it? I didn't bother to investigate; I recomipled and the problem went away. > --enable-threads, or vice versa. Probably what happened to you? Don't think so. The 1.8.3 was from Ubuntu Hardy. I assume it had threads turned on; but I wasn't yet using threads at that time, so I don't know. The 1.8.5 was self-built. I did not specify --enable-threads, this seemed to be on automatically. --linas
Re: Guile release planning
Hello! "Neil Jerram" <[EMAIL PROTECTED]> writes: > In my view, the most important thing for Guile's near-to-medium-term > future is focus. By that I mean having developers working on, and > users using, as far as possible, a similar level of code. In the > past, we did big jumps - from 1.4.x to 1.6.x, and from 1.6.x to 1.8.x > - which I think left users unable easily to upgrade, or perhaps just > unsure of whether to upgrade. From the developer point of view, they > increased the support burden (because of some users staying with the > old series). Also the big jump model can be frustrating for > developers, because it tends to mean that there is a long time between > when a shiny new feature is ready, and when it gets released and so > into the hands of most users. I fully agree with this, but... Your note doesn't take binary compatibility into account, and I think it's an important thing, too. I think the ideal is to maintain binary compatibility within a major series, as we've done (or tried to do) in the 1.8.x series. This is very convenient for binary distributions like Debian, and for users in general. Thus, introducing ABI incompatibilities should imply increasing the first or second digit of the version number, IMO. Maintaining ABI compatibility doesn't mean we can't add new features, though. In the course of the 1.8.x series, several Scheme modules were added. I think enhancements like the lazy symbol binding in modules could have been in theory added in 1.8.x since it breaks neither the API nor the ABI. Things like `libguile-i18n' could have been added too, but the issue when adding C code is portability: it may be that this module would have caused build issues on some platforms. Now, with more frequent releases, it would be reasonable to hope that such regressions would quickly be fixed. Another thing is actual big jumps. I think the addition of the VM is a big jump. A GC change, or a rewrite of the string/char code with Unicode support would be a big jump, too. Such big jumps surely need a new major release. BTW, we need to consider releasing 1.8.6 one of these days! ;-) Thanks! Ludo'.
Re: Guile release planning
Hi Linas, On Tue 11 Nov 2008 04:44, "Linas Vepstas" <[EMAIL PROTECTED]> writes: > 2008/11/10 Neil Jerram <[EMAIL PROTECTED]>: >> >> I also think it will help us manage API incompatibilities better. I >> think our default position from now on should be to maintain >> source-level (API) compatibility, but it is inevitable that there will >> be exceptions to this. > > Any ideas for binary compatibility for the "micro" revisions? I think it needs to be guaranteed. > I recently discovered that a library compiled against 1.8.3 > would core dump when used with an application compiled > against 1.8.5. Ooh, bummer. The 1.8 series is binary-compatible (i.e. 1.8.x is compatible with 1.8.y if x >= y), *but* only if compiled in the same way. An example of compiling in different ways is if you build against a guile with --disable-threads, but then rebuild guile with --enable-threads, or vice versa. Probably what happened to you? > The linux kernel got rid of the stable/unstable branch idea, > and it's worked really really well. (the reasons why are > widely documented) I'm for it. The linux kernel doesn't guarantee ABI /or/ API stability -- it's a different kettle of fish. Cheers, Andy -- http://wingolog.org/
Re: Guile release planning
Hi Linas, "Linas Vepstas" <[EMAIL PROTECTED]> writes: > Any ideas for binary compatibility for the "micro" revisions? > I recently discovered that a library compiled against 1.8.3 > would core dump when used with an application compiled > against 1.8.5. Do you remember what caused it? I don't remember of any ABI change in the 1.8.x series (apart from function additions). The with-threads and without-threads Guiles are not ABI-compatible, though. Thanks, Ludo'.
Re: Guile release planning
Any ideas for binary compatibility for the "micro" revisions? I recently discovered that a library compiled against 1.8.3 would core dump when used with an application compiled against 1.8.5. Operationally, not a big deal, really; I just recompiled the lib, but emotionally, it did give me that sinking feeling for a while, of maybe having yet another hard-to-find bug, or a system I cannot fully trust. :-( The first question is if there was a shlib minor version bump. But, if it were the other way around it would be bad. It is not expected in general that you can use older libraries than what you built against. But, building against 1.8.3 and then updating to 1.8.5 should be ok. pgpZks8eh1jNE.pgp Description: PGP signature
Re: Guile release planning
2008/11/10 Neil Jerram <[EMAIL PROTECTED]>: > > I also think it will help us manage API incompatibilities better. I > think our default position from now on should be to maintain > source-level (API) compatibility, but it is inevitable that there will > be exceptions to this. Any ideas for binary compatibility for the "micro" revisions? I recently discovered that a library compiled against 1.8.3 would core dump when used with an application compiled against 1.8.5. Operationally, not a big deal, really; I just recompiled the lib, but emotionally, it did give me that sinking feeling for a while, of maybe having yet another hard-to-find bug, or a system I cannot fully trust. :-( > the steady new feature model is better. The linux kernel got rid of the stable/unstable branch idea, and it's worked really really well. (the reasons why are widely documented) I'm for it. --linas
Re: Guile release planning
If the base Guile C API remains stable, it doesn't matter to me how the releases occur, because they won't break my libraries or projects. If the Guile C API needs to change, some sort of notification and beta pre-release would be preferred, so that I can test my projects before the new Guile gets yum'ed out to my group. -Mike Gran
