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

On 08/27/13 13:55, Matthew Flatt wrote:
> For what it's worth, I think you're worried about problems that will
> have simple solutions in practice. For example, I don't think you
> should rely a package whose author isn't invested enough to at least
> put it on GitHub or otherwise archive old versions.
>
> If one of your scenarios turns out to be a problem in practice,
> however, then you should expect that we will improve the package system
> to address the problem. That is, don't expect the package system to be
> perfect, but do expect us to respond to concrete problems.
>
> That opinion points to my general answer about relying on Racket for a
> commercial enterprise:
>
>   * You *cannot* rely on on Racket version X.Y.Z as the prefect design.
>
>   * You *can* rely on Racket to keep changing and keep improving. It's
>     natural and appropriate to worry about change and/or new designs,
>     but we are committed to change and improvement, anyway.
>
>   * You *can* rely on Racket to provide backward compatibility and/or a
>     migration path so that your programs keep working as Racket
>     improves.
>
> As a case in point, this thread is about the new package system. We
> have an old package system (PLaneT), and it is still supported. We're
> building on the experience of the old system to solve some of its
> problems and to create new opportunities. I have various reasons to
> believe that the new package system is a step in the right direction
> (not the least of which is the fact that DrRacket can now be a
> package), but I'm even more sure that's the design is as good as we can
> do without further practical experience.
>
> Past performance is no guarantee of future results, as they say --- but
> maybe past performance is the best indicator available, anyway. Racket
> has been around for a while, so you can see how we work, and that
> should help you decide whether Racket is stable enough to build on.

I spent some time looking at the Racket code, tests and mailing lists 
before choosing it. I don't
seek perfection and have been very impressed with how responsive the 
racket development
process has been.  I am therefore sure that as problems arise, they will 
get sorted.

I am not against the new package management system per se, and agree 
that separating
out the parts that make racket into packages is a great idea.  It is 
purely the lack of version
control and parallel version handling that I am concerned about.  I have 
seen problems with
version control crop up for so long and so often that I can't see why 
people think Racket and it's
third-party packages would be immune to what has happened in every other 
package eco-system
I have used: Ruby, Tcl, Shared C Libraries under Linux, Various Linux 
Distros, etc.  All of these either
started without distinct version control, or started with a single 
version package model and now all
support multiple parallel versions of packages to overcome the 
dependency problems that arose.

Developers make mistakes, we are all human, no one knows what another is 
going to do and we can't
control it; all we can do is mitigate the risks.

I assume Racket itself is not going to drop distinct release version 
numbers for some of the same reasons
that I am worried about this.  In addition if it did then documentation 
would be a pain, as it will be for
packages under this new scheme.  Answering questions on this mailing 
list would be a pain, e.g.  What
revision of Racket are you experiencing that problem with?....Uh 
checksum 0xA3B432DE34F45C43...Ok,
I'll look that up and work out what state the API was in then.

For the moment I'm going to leave this and see how things get on and 
report back if I have any problems.


Lorry

-- 
vLife Systems Ltd
Registered Office: The Meridian, 4 Copthall House, Station Square, Coventry, CV1 2FL
Registered in England and Wales No. 06477649
http://vlifesystems.com