[racket] Worried about the new package manager not storing each version of a package

At Thu, 29 Aug 2013 14:47:03 -0400, Greg Hendershott wrote:
> On Thu, Aug 29, 2013 at 3:28 AM, Lawrence Woodman
> <lwoodman at vlifesystems.com> wrote:
> > On 28/08/13 18:21, Greg Hendershott wrote:
> >> ...
> >> 2. Use Semantic Versioning (although Matthew IIRC it would need to
> >> support versions like "2.0.0" and "0.0.1" that it currently rejects?).
> > ...
> > In your mention of semantic versioning (http://semver.org for anyone
> > not familiar), you say about versions < 1.0  I'm currently using version
> > v0.2.1 as the version of my xdgbasedir package without problems, so
> > I don't think its an issue, unless it comes up when specifying a dependency.
> 
> My explanation from memory was wrong.
> 
> Instead: You can't (fully) use semantic versioning because the patch
> number can't be 0. For example "0.1.0" isn't allowed.

Package versions are intended to be like semver, but they differ
syntactically because

 * the major number should be part of the package name, and

 * the major number "1" is written "".

So, write xdgbasedir version 0.1.0 as package name "xdgbasedir0" and
version "1.0".

> If I've followed the discussion/history correctly (a big "if", there's
> been a lot of it) then I think it's important to remember that the
> package manager is infrastructure with the primary _initial_ mission
> of allowing Racket itself to be "package-ized". Although it can
> already _also_ be used for third-party packages, it's not (yet)
> attempting to be the ultimate third-party-package manager. It's not
> trying to be "Racket's answer to gems", for instance. As a result
> today it's both more flexible and more limited than you might ideally
> want for a third-party-package manager. So while Matthew and the core
> devs are still busy wrapping up the _initial_ main mission
> (package-izing Racket, and the huge source re-org associated with it),
> the rest of us may need to do, by convention, some things we might
> prefer automated and/or enforced someday. That's my take on it,
> anyway.

No, the intent is to be the manager for "third-party" packages.

Package-izing the main distribution was a secondary mission. Breaking
up the distribution has helped, I think, to ensure that the package
system can be good enough for its primary mission, but the goal is to
better support "third-party" packages.

In fact, we want to get rid of the notion that the packages that are
currently in the main distribution are special --- at least, not in any
way except that they happen to be selected to be in the distribution
that PLT provides right now. That's why I keep putting "third-party" in
quotes; all packages are considered "third-party" by the package
system.