backward-compatibility

[Neil Van Dyke]

The perpetual backward-compatibility requirement of the package system
policy is still (including this morning) creating headaches for me, as a
party who is trying to maintain open source packages for things that I
develop and use for my own purposes.

If the package system isn't going to get a notion of
backward-incompatibility like PLaneT had (which, together with
simultaneous multiple-installed-version support, was 95% of what I
wanted), then...

Just tossing out an idea here, to prompt discussion, not proposing it...
What if it were within policy for a package author to introduce a
backwards-incompatible change, *iff* the author is reasonably confident
that it wouldn't break any users of the package *that have the code in
the official open source package catalog*. Then, the author could see
which other packages in the catalog use the author's package, and
inspect the code of those, to see how their use the package would be be
affected by the change.

This is idea is *not* good for software engineering (only a consumer
should be saying whether a spec change is OK to them; that's not the
provider's place). And also, closed-source users of packages would get
screwed, and likely end up maintaining diverging private forks of open
source packages they use without contributing changes upstream.

However, the current package system policy is onerous for third-party
package developers who are sharing some of their code as open source,
but need to do ordinary backward-incompatible changes without the open
source being a huge extra burden on that practice. The current policy is
begging for third-parties to abandon the open source version and go back
to closed as their code evolves, or to simply violate package system
policy and start breaking people.

So, while this idea I'm tossing out is a groaner, and I don't like it,
it might still be a better compromise than the current situation.
Discussion?

Neil V.

[Vincent St-Amour]

On Mon, 21 Mar 2016 11:06:02 -0500,
Neil Van Dyke wrote:
> Just tossing out an idea here, to prompt discussion, not proposing
> it... What if it were within policy for a package author to introduce a
> backwards-incompatible change, *iff* the author is reasonably confident
> that it wouldn't break any users of the package *that have the code in
> the official open source package catalog*. Then, the author could see
> which other packages in the catalog use the author's package, and
> inspect the code of those, to see how their use the package would be be
> affected by the change.

Not a great solution, but here's what I've been doing.

- Make a local copy of the package catalog (with `raco pkg catalog-archive`)
- grep -R for the package/collection name

Vincent

[Jack Firth]

It would be great if (opening words to many a pipe dream but nevertheless) the package catalog UI directly included information about what other packages are dependent on a package, at least for the purposes of package developers. This is useful information beyond backwards-compatibility concerns, as it makes it easy to track down the source code of clients to see how people are actually using your package. It's also a good indicator of how "core" a package is and how supported it is, fringe package X with zero clients could be completely broken and nobody would notice while commonly used package Y which a fifth of the catalog depends on can be relatively trusted. 

[Vincent St-Amour]

Not integrated with the package catalog, but there's the package graph
visualizer:

https://docs.racket-lang.org/pkg-dep-draw/index.html

Vincent

> --
> 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 racket-dev+...@googlegroups.com.
> To post to this group, send email to racke...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-dev/4f015c2b-1bd2-4f1e-bca1-0e0782ecad32%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.