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