[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
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".
> 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.
Regards
Jonas
signature.asc
Description: This is a digitally signed message part
- Re: Test reader speed of Guile 3.0.6, (continued)
Re: Test reader speed of Guile 3.0.6, Han-Wen Nienhuys, 2021/03/12
- Re: Test reader speed of Guile 3.0.6, Han-Wen Nienhuys, 2021/03/12
- Re: Test reader speed of Guile 3.0.6, Dr. Arne Babenhauserheide, 2021/03/12
- Re: Test reader speed of Guile 3.0.6, David Kastrup, 2021/03/12
- Re: Test reader speed of Guile 3.0.6, Dr. Arne Babenhauserheide, 2021/03/13
- Re: Test reader speed of Guile 3.0.6, Jonas Hahnfeld, 2021/03/17
- Re: Test reader speed of Guile 3.0.6, Dr. Arne Babenhauserheide, 2021/03/17
- Re: Test reader speed of Guile 3.0.6,
Jonas Hahnfeld <=
- Re: Test reader speed of Guile 3.0.6, Dr. Arne Babenhauserheide, 2021/03/18
Re: Test reader speed of Guile 3.0.6, Han-Wen Nienhuys, 2021/03/13
Re: Test reader speed of Guile 3.0.6, Dr. Arne Babenhauserheide, 2021/03/13
Re: Test reader speed of Guile 3.0.6, Han-Wen Nienhuys, 2021/03/14
Re: Test reader speed of Guile 3.0.6, Knut Petersen, 2021/03/19