Maxime Devos <maximede...@telenet.be> writes: >> But when the culture shifts so people say “hey, we have versioned APIs >> now, let’s change everything around to fit this new style; it won’t >> break existing clients (until we remove the old version)” (can you say >> that you never saw people do that? I did see it), then it causes serious >> problems.
> Someone else said to remove the old version, not me. It’s how this thread started, so that’s what I’m talking about. I comment on the case without deleting them at the end. > It also probably does not, because ‘equal?’ from (rnrs base (7)) would > likewise be the same as (rnrs base (6)). > > Also, this is allowed, because (IIRC) (rnrs something (6)) has an API where > you specify _which_ hash and _which_ comparator – so it doesn’t care > which comparator and hash (as long as they are compatible with each other and > the comparator is, in fact, a comparator (reflexivity, > transitivity, symmetry)). In particular, it breaks nothing. It breaks nothing right now, because people took care to keep the semantics the same. They cared about backwards compatibility. But this is what changes if we use versions as reason to ignore backwards compatibility. > This does not increase the testing area, because the testing area of > (rnrs something (6)) is already infinite since it can’t care about > which comparator in particular it is passed – 2*infinity = infinity > for most notions of infinity. This is sophistry: leaving out that there are non-infinite parts of this infinity which are important to tested for most use-cases — and that these non-infinite parts double. > I also never claimed that versioning is a panacea. Then I misunderstood you, because all I am doing is to warn, that versioning APIs to make big changes has drawbacks and risks a cultural shift towards breaking backwards compatibility. I’ve seen this with Python 3. It shows again with Rust. Scheme implementations have a pretty good history of backwards compatibility and making that worse is what I worry about. > Can you stop it with the strawmen? It’s only a strawman if it isn’t real. I am showing you examples where it leads when version numbers are treated as a free pass to break backwards compatibility. This is not a strawman, but the risk I see when a warning not to break backwards compatibility is answered with “we need versions”. >> That’s why I say that the load of backwards compatibility cannot be >> removed: it can only be shifted on other people. > > This is false, you can also shift it on yourself (i.e. whoever does a bunch > of renamings, also changes the version number and under the old > version number adds some bindings referring to the new names in the new > version number). > > I guess this is technically a ‘load’, but the effort required is so minimal > that this is hyperbole. It sounds like this is the main point where our opinions differ. I do not consider this effort as minimal. It may look small with the first change, but it grows more than exponentially, because if you want to give a guarantee, every version has to be tested against every combination of already existing versions. > what would be the problem with _renaming_/ _relocating_ when the old names > are still preserved? Off the cuff: You now have two sets of documentation to keep in sync (including tutorials that no longer match the best-practices), you must ensure that the implementations stay the same, you get code using mixed and matched module hierarchies, dependent parts can get imported with different names depending on which best-practices their authors followed. Best wishes, Arne -- Unpolitisch sein heißt politisch sein, ohne es zu merken. draketo.de
signature.asc
Description: PGP signature
