On 09/11/2006, at 1:27 AM, Xavier Hanin wrote:
hat's why I began to thought about using compatible metadata
revision, so
that you never break anything. Whenever you want to change the
metadata of a
module, the only thing you can do is to add new configurations, and
maybe
deprecate others. The metadata revision is identified in the file
by an id
(which could be simple incremental number, or by a timestamp/user
uple as
you indicate) Each configuration declares in which metadata
revision it has
been introduced/deprecated. By default when you depend on a module you
depend on its first metadata revision, unless explicitly specified
(specifying a specific revision or the latest one if it makes sense).
This is basically the conclusion we arrived at too (which I now
recall as being nearly 12 months ago, horrified that we still haven't
gotten around to implementing it :)
This was kind of the original purpose of the "build number", being
for re-releases and external packagers. However, I think it needs to
be a built in concept like you mention, rather than part of the main
version.
I'd suggest always using the latest metadata, but locking it down to
a specific revision when you produce the release (like you would with
a version range) for reproducibility.
This does mean that we need overall more effecient ways to check for
updates in the repository than testing every file once a day, which
is something we are moving towards with the repository index.
Cheers,
Brett
