My super-strongly preferred engineering notion: backward-compatibility
of a package refers to the *documented* behavior of the package, not to
actual behavior.
For the moment, disregard the exception cases arising when actual
behavior of a version doesn't comply with documented behavior for that
version. I think it's important to focus first on human
expression&interpretation of *documented* behavior. Developing to
interface documentation (like to specs of a bolt from the manufacturer)
helps a lot of engineering processes work, especially between
organizations. I think that this "between organizations" should be the
usual case with the package system.
(Even if you had some breakthrough halting-problem-transwarp approach to
determining backward-compatibility programmatically, with a pretty
DrRacket smiley/frowny-face icon indicator, I would still expect to be
able to work from the English documentation of behavior. I'm not
ignoring the possibilities of unit tests and formal specification, but,
at the end of the day, I think your documentation needs to be
human-readable, for preferred engineering processes as we know them to
work.)
Neil V.
--
You received this message because you are subscribed to the Google Groups "Racket
Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/racket-dev/55E47208.7030508%40neilvandyke.org.
For more options, visit https://groups.google.com/d/optout.
