unification of defsystem with my other proposal

[<do...@co...>]

It occurs to me that the form I proposed could, in fact, be
a defsystem form.  I think only small changes are required to
defsystem:
 - allow arbitrary keywords in the defsystem form
   these will be ignored by defsystem, but other tools can read the
   same definition and use them
 - (This may not require any change) the components must be  allowed
   to include a version

The idea is that when you want to release a version of a system
you change the source pathnames to use the appropriate versions
and put the resulting defsystem file in my database directory with
the release version (possibly the version will have to be part of
its name in order to avoid defsystem knowing how to use cvs). 

Now some other responses ...

  > To start off with, I dislike putting stuff into :user :-).
I agree.  My only excuse for a couple of my files is that they
were not meant to be called by other packages or saved in images,
rather just for development.

I also don't like systems to change other shared resources such as
the standard read table, *features*, redefining lisp symbols, ...
unless really necessary and explicitly documented where you can't
miss it.

  > At least :files, :requires and :packages can/should be in the defsystem
  > description. The others are just windowdressing...
Packages are not part of defsystem.  I think the others are not just
windowdressing.  There's more to life than knowing how to build.

  > > So, in order to "release" a new version, you create a new version of
  > > the description file containing the appropriate data.  I assume that
  > > existing versions of files never change, though in this case it would
  > > be useful to delete a version if you find you made a mistake in the
  > > description.  The repository then contains lots of versions of files 
  > > that are not in any released system, but you can easily find out which 
  > > versions are expected to work together.
  > 
  > This isn't how CVS works. Sourceforge uses CVS. If you want to do
  > something different, go right ahead.

Yes, it is how cvs works.  You create new versions of files.  There
is no restriction on how they are interpreted.  I choose to interpret
most of them as current source and a few as descriptions of released
systems.

  > <flame>
  > All that "versions are expected to work together" stuff is just bogons
  > clouding your judgement. I think you've worked too long with microsoft
  > junk, if a program "doesn't work with X version Y" then either that
  > program or X is br0ken and should be fixed.
  > 
  > I _refuse_ to add work to my workload to document bugs that should be
  > fixed!
  > </flame>

Ok, I admit this qualifies as a flame.  I completely disagree with it.
If Y version 2 contains different interfaces than Y version 1 then
it's not reasonable to expect X version 3 which was written using Y
version 1 to continue to work with Y version 2.  Nor is it reasonable
to expect the person writing X version 4 which uses Y version 2 to
arrange for X version 4 to also work with Y version 1.
This has nothing to do with Microsoft.