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 racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/racket-users/2355bc5c-09da-5c46-b002-2ae03c69329f%40neilvandyke.org.
