For a given package `foo`, the general idea regarding new changes that as
I've understood it is:
1. Changes to existing functionality that break things belong in a new
package `foo2` that provides differently named modules/collections from
`foo`, since it's essentially completely different behavior. This allows
both `foo` and `foo2` to be installed at once, such that code using the old
package can coexist with code using the new one. This also means unless you
explicitly choose to use the changed functionality by requiring `foo2`,
your code won't break, and you can selectively upgrade parts of a codebase
to use `foo2` instead of having to upgrade the whole shebang at once.
2. New features should up the version number in the package's
`info.rkt`. This means different package sources for the same package name
can declare which features are available, and client code can define a
minimum set of features it requires.
3. Bug fixes and other changes to existing functionality that don't
break things for well-behaved clients (for some reasonable definition of
"doesn't break things" and "well-behaved clients") don't really need to
update the package's `info.rkt`, but it would be a good idea if they did.
They should increase the version number less than new features do (e.g. 1.0
-> 1.1 instead of 1.0 -> 2.0). This gives more flexibility to client code
feature specification, a client package can say "I really want 1.0, but it
has a bug in it that wouldn't be fixed until 2.0, but 2.0 has features I
don't need".
4. For packages whose name includes the author name, e.g. "jack-mock",
or for modules or collections in the "unstable" collection, all bets are
off. Existing functionality may change without warning, new stuff could be
added, old stuff could be removed, multiple times a day. This gives package
authors ways to experiment with published code while warning clients of
experimental behavior.
At least, this is how I've been attempting to do things recently. It seems
like a pretty reasonable way of working. The biggest problem thus far with
this workflow is that if a package `foo` says "I require version 2.0 of
package X", the package catalog can only give you the most recent version
of package X. This isn't a major issue if package X is well-behaved
regarding backwards compatibility, but as these are social rules and not
technical ones, outliers will exist. The "safest" thing for installation to
do would be to install version 2.0, as it's the closest match to the
features required by `foo`.
In order to support this, would it make sense for the package X to have
something like this in it's info.rkt?
(define version-sources
(hash "1.0" package-source-for-foo-1.0
"1.1" package-source-for-foo-1.1
"2.0" package-source-for-foo-2.0))
I think it would be possible for the package catalog and package build
server to use this information to figure out what to do with requests for a
particular version of a package name. I don't know enough about the
implementation of that infrastructure to know how feasible this is however.
What are some alternate ways of versioning packages? Should this process be
documented and referenced by the package catalog website? Or the main
racket documentation on packages?
--
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+unsubscr...@googlegroups.com.
To post to this group, send email to racket-dev@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/racket-dev/715bb22a-12e7-4d51-bdd3-f91f5a80c6ad%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
