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

Matthew Flatt wrote at 08/29/2013 03:14 PM:
> 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.
>    

One distinction that I'm not sure was articulated, between pieces of 
DrRacket and what I'd call an ecology of reusable third-party 
components, is in the who/what/when/where/why/how of the components' 
lifecycles.

Few third-party developers have releasing Racket third-party packages as 
part of their job descriptions, and third-party contributions seems to 
largely be altruistic.  As for altruism, I can attest that trying to 
promote Racket as a third-party R&D person for the last decade has not 
shown financial returns like simply riding the popularity of some other 
platform would've.  And third-party packages aren't often part of a 
tenure bid, nor listed on many grant applications.  When packages aren't 
coming from PLTers and random grad students (who might get academic 
career traction out of it, in addition to the altruistic and vision 
factors), I think packages are generally coming from hobbyists and maybe 
sometimes from businesses.  In the case of businesses, they're often 
toying with the idea of giving back, perhaps for hiring PR, or indulging 
some valuable employee's interest in open source, if it's not too 
expensive to do so.  The third-party motivation seems generally 
altruistic or fragile/fleeting.

In my particular evolving R&D vision for an ecology of reusable 
third-party components, and how that might happen without without 
encumbering the agility of third-party developers who decompose their 
apps to include reusable components that can be open-sourced almost 
incidentally (e.g., easy to release and update, backward-incompatible 
changes are OK), as well as making stable apps developed using large 
numbers of these components practical (e.g., managing and mixing 
versions, and a compatibility info/mechanism)... there are very 
different needs than DrRacket has had thus far.  An initial cut at 
breaking the DrRacket code base into packages will not encounter and 
have to address many of these different needs.

A hypothetical exercise: If, after DrRacket has been broken into 
packages, all the PLT developers cease speaking with each other for a 
few yeas, and release changes to their respective pieces of DrRacket 
only as weekend hobbies, or by sneaking it past their employers, and 
they start building important things upon numerous other third-party 
components, and they start seeing surprise incompatibilities between 
components that breaks their important apps, and problems mixing apps 
and components with incompatible version dependencies... then, even 
though they had the freak advantage of a long-centralized starting point 
for their packages, then they might start to appreciate lifecycles like 
real third-party packages, and apps of same, will.

That's why I'll continue to say "third-party" without quotes around it, 
for now. :)

Neil V.