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
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
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
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
>> co
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. Exa
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 d
"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
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-spre
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
> 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 t
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
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 bet
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 d
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
> th
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 -
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
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 a
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
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) compatibil
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 r
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
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
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
Andy recently wondered - in connection with his VM implementation and
docs - about when a 1.9.x or 1.10.x release might happen, and that
reminded me about the following thoughts that I've been trying to
crystallize for a while. How should we organize future Guile
releases? I'm interested to hear
24 matches
Mail list logo
