> A related issue is that examples in the documentation sometimes > fail in a way that indicates a bug. By having that failure be a > documentation-build failure, instead of rendered as an error > message in the documentation, we can avoid some errors in a > release. Matthew will add a replacement for `examples` where forms > that are intended to be rendered as errors must be explicitly > marked as such, while other errors trigger a document failure.
This, along with a fixed eval:check, is a wonderful change. Documentation examples that also serve as an ad-hoc test suite is a pretty cool idea. I’m very excited to be able to use these. There is a problem, though: I can’t use them without dropping support for older Racket versions because these are entirely new forms. This was something I was thinking about lately: having monolithic “releases” makes it impossible to backport changes to older Racket versions. For example, the new scribble/example(s) module seems like something that would work with lots of Racket versions were it a package, but since it’s part of the core, scribble-lib will be locked to older versions on old releases. Am I wrong about this? Maybe it would work if I explicitly depend on a newer scribble-lib version? I think I’m a little unclear about that. Anyway, that’s a tangent. These all seem like good decisions, and I’m interested to see them be applied. Alexis -- 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/A40053BA-4793-4D26-B491-0E9F46131F15%40gmail.com. For more options, visit https://groups.google.com/d/optout.
