Re: [oc] Automatic Core Metrics and Documentation

[Graham Seaman <graham@seul.org>]

On 9 May 2003, Rudolf Usselmann wrote:

> > A version number really ought to be in the basic info. Something like the
> > standard software major/minor version number would be good. At the moment
> > I have given up on trying to track opencores cores on opencollector.org 
> > because of this lack - and I'm only trying to list them, never mind make
> > use of them!
> > 
> > Graham
> > 
> OC, uses CVS, most cores should be trackable by that. I
> know I always add a CVS header in my source code that
> automatically is updated by CVS.
> 
Yes, but it's the existence of a more visible convention that helps more
than the technical details. With software, I generally know that version
0.001 is just a preliminary sketch, that version 1.1 ought to work out
of the box, and that the step from 1.2.1 to 1.2.2 is likely to be trivial
while from 1.2.1 to 1.3 its likely be a big improvement. And I can see it
usually by looking somewhere on the download web page.

For the cores (unless I'm missing something on a page somewhere) I have
to download the package, untar it, then grep for the version number. And
then it seems that with some of the cores on opencores, different files
have totally different version numbers (or none), and there's no overall
version for the package. If it was possible to look at the project list 
and see not 'done', but 'version 0.1', 'version 1.0' etc it might be a
better way for people to get a preliminary idea of how worth it is looking
at a core, and also stop people who've downloaded something that's
really only version 0.06 from complaining about the quality...  

Best
Graham



--
To unsubscribe from cores mailing list please visit http://www.opencores.org/mailinglists.shtml