Re: Re: third-party package tips and developer concerns (Was: New version of file-watchers)

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