Sage Gerard wrote on 8/31/19 10:38 AM:
You probably don't want to be slowing yourself down with offering people 
previews of new versions, lead times for input, etc.
I'm unknown in open source so

I think all of us in Racket land are pretty much unknown in open source (outside of Racket/Scheme). :)

creating as many opportunities as possible for feedback is valuable enough to 
be worth the effort.

OK, if you want the input, or are willing to do that extra work, that's great.  I only meant it as I said it: I wanted people considering being third-party package developers to know they weren't obligated to take on that extra burden if they don't want to.

Re: deprecation, I strongly believe that less code is better, and I hope that I 
can draw compromises with users on doing things like remove redundant 
functionality on my own.

That sounds reasonable to me, if that's how you want to do it for your packages.

If a third-party package developer expects to possibly break backward-compatibility in the future, it might make sense for them to indicate that near the top of their package documentation.  That makes the social contract more clear.

(I don't think there was much buy-in on that backwards-compatibility policy for third-party packages, which was handed down to replace the lost PLaneT version support.  It was core-centric, and burdensome to third-party developers who are doing rapid/agile research/move-fast-and-break-things, and/or open-sourcing parts of a system on which they do things like global refactoring, and want to be able to make backward-incompatible changes to their code.)

the style guide

That style guide applies only to the code of core Racket itself, not to third-party packages.  You can look at it for ideas, or adopt it as a bible, if you want, but do your own code however you like.

I think a general theme in these comments is to encourage important and sensible things for package developers (e.g., create package metadata and catalog entry, do a versioned release of some kind, consider including documentation and tests, consider naming things to work well with doc search and code readability), but not burdens that people will often either ignore or find too discouraging to do anything at all (e.g., you don't have to format your code a certain way, you don't have to preserve backward compatibility with each version, you don't have to Scribble).

You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
To view this discussion on the web visit

Reply via email to