Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
> > - The data becomes obsolete quickly. You can take a look
> > at clisp's unix/PLATFORMS file
>That's actually pretty close to what I want.
I believe adding entries to that list is the only reasonable thing to do. The rest sounds like full time jobs (maintaining DB, build old versions etc.), nobody has time for that.
>I see lots of reports for linux, but the most recent is 2.2.13 in
Unfortunate. People, please containue to add entries there.
It's important for practical applications that some known version of CLISP still works with old OS.
E.g. I just have a project where the OS is Suse Linux 8.1, which some may consider old already (9.1 may be current, I don't follow releases) -- FWIW, it successfully builds current CVS clisp.
Not every hardware is as new as the developer's favourite development box.
> > Look into the CVS's NEWS file, and on the bug tracker.
I too believe NEWS and ChangeLog give a lot of information about specific bug fixes.
But the mailing lists archives are equally valuable, because they give context and history, failure and success stories.
E.g. if you have an OS from 2000, use a CLISP from 2000 -- I probably wouldn't consider a binomial test build of all releases in between to find out which one stopped building: either the newest one can be made to work again, or it's very likely to be too expensive to fix more than a few annoying bugs in an old one.
Most of the bugs that get fixed *I* have never ever noticed. So fixing 1-3 specific bugs in a CLISP from 2000 may be good enough for use in some environments.