Re: Test reader speed of Guile 3.0.6

[Dr. Arne Babenhauserheide]

Jonas Hahnfeld <hahnjo@hahnjo.de> writes:

> Am Mittwoch, dem 17.03.2021 um 23:05 +0100 schrieb Dr. Arne
> Babenhauserheide:
>> Jonas Hahnfeld <hahnjo@hahnjo.de> 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.
> https://semver.org/ 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".

Note the "may" here. But some context is in order (as far as I got it by
lurking): The previous reader implementation caused problems with
suspendable ports. The new scheme-based implementation is intended to
fix that.

The internal changes are bigger, but the functionality should not
change.

(note the "should" here — that’s why I’m asking for testing with you,
because I know that Lilypond is likely the most advanced power-user of
the Guile reader)

>> 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.

No, we’re actually testing the speed. But we have no complete
performance testsuite.

> The fact that you're approaching LilyPond to
> test things means that you're not sure, even before releasing.

Before you actually make a new release, you can never be sure that there
won’t be any regressions.

But you are making a solid argument for going to a new minor release.

> 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.

That’s what my personal goal is, and as far as I can tell that’s also
what the goal with this change is.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken

signature.asc
Description: PGP signature