[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Test reader speed of Guile 3.0.6

From: Jonas Hahnfeld
Subject: Re: Test reader speed of Guile 3.0.6
Date: Thu, 18 Mar 2021 08:51:58 +0100
User-agent: Evolution 3.38.4

Am Mittwoch, dem 17.03.2021 um 23:05 +0100 schrieb Dr. Arne
> Jonas Hahnfeld <> writes:
> > IMHO not including a major rewrite of the entire reader into a bug-fix
> > release should have been the first step. Right now, if we asked for
> > guile-3.0 during configure time (which we don't), we would have no idea
> > which one we get. Really, there must be some truth to the idea of
> > semantic versioning...
> Semantic versioning is about the APi — which this should not change. So
> from semantic versioning a change of the implementation is not a
> problem.

Let me disagree, semantic version is about more than the API: It's
about giving guarantees what users / developers of downstream projects
can expect from a given version change. is quite clear that "Patch version Z (x.y.Z | x >
0) MUST be incremented if only backwards compatible bug fixes are
introduced. A bug fix is defined as an internal change that fixes
incorrect behavior." which I'd argue a complete rewrite is not.
Instead "Minor version Y (x.Y.z | x > 0) [...] MAY be incremented if
substantial new functionality or improvements are introduced within the
private code".

> If there are serious performance regression, then I think that this
> needs to be addressed, though, because then the practical use of the API
> would be impacted.

The problem is that you're gambling here: By introducing the new reader
into a bug fix release, you're *hoping* that there is no such serious
performance regression. The fact that you're approaching LilyPond to
test things means that you're not sure, even before releasing. As such,
I consider such rewrite inappropriate for a bug fix release.
Consider what happens if there's a problem in 3.0.6 that is only fixed
in 3.0.7 (or later!) and seriously deters LilyPond, Guix, ... - what
should the projects do? Should they check for that broken version in
their configure scripts? That's really not how distributions bring
updates to the users, ie a dependent project must "just work" with a
bug fix release.

But of course, all of this is just my personal opinion. However, I
would urge you (and the Guile project) to seriously take these points
into consideration.


Attachment: signature.asc
Description: This is a digitally signed message part

reply via email to

[Prev in Thread] Current Thread [Next in Thread]