Future handling of API changes

[fschulze]

The API changes in 6.x were done in a backward incompatible way, for the future it would be nice if that wouldn't be the case.

At least for the changes in 6.x I think it would have been possible to handle them with deprecation warnings and no breakage.

For restrict, the projects keyword could have created LegacyProjectNamesRestriction and add a deprecation warning when used.

The old class names could have been wrappers functions which issue a deprecation warning and return the corresponding Legacy class.

I know it isn't always possible or just harder to maintain backward compatibility, but full on breakage is bad user experience.

[ewjoachim]

Hello :)

I hesitated a lot before doing it. Part of the reason I didn't put a lot of effort into backwards compatibility is that I have very little feedback from lib users. I don't know if people pin the minor, or the major version or anything. I've been pretty liberal in the previous compatibility breaks, and given no one was using the lib, it wasn't a problem. You'll note that I increased the major version, and issued a special documentation :)

Now to the why: I mainly wanted to avoid having to resort to second choice keywords for the new restriction class names & restrict arguments (which, hopefully are here to stay).

At least for the changes in 6.x I think it would have been possible to handle them with deprecation warnings and no breakage.

Yes for ProjectsRestrictions but DateRestriction couldn't. There was a clash both with the name DateRestriction which was the ideal name for the new restriction. And restrict(not_before/not_after). I think if there had been no good reason to rename anything, I might have kept it all, but it's really DateRestriction that convinced me to do it.

Now that's all said and done, I'm aware now that there are people who would prefer I don't do that in the future, and also, I can retroactively add a compatibility layer for all the parts that are unambiguously legacy.

And finally... You seem to have an interest in the library... Do you want to take part into its development ? It's a good way to avoid future problems :)

[fschulze]

I would not (edited) bother with adding something retroactively, especially if DateRestriction is a bigger problem than I thought. I fixed it on my side already and it is quite likely I'm the only user of that feature currently. I know the feeling of not getting feedback and only when something breaks people come out of the wood works.

I can happily test changes before releases. Beyond that I have enough on my plate already. But just ping me if you want my input on anything and I will do my best to reply in time.

[ewjoachim]

Great ! I'll keep you in the loop if anything comes up.