Gilles Scokart wrote:
Personaly, I agree with Xavier.
A released artefact AND the attached metadata can not change once released.
It's exactly the purpose of a release.
Of curse error happens... (often). If the user want to take that into
account, he should add a build number to its versions numbers to handle
that.
At most, I could accept an informative flag added to the metadata saying
that a release is deprecated or invalid.
But for me, once it is released, nothing can be changed.
Gilles
this works for an in house project, and I strongly agree with freezing
binary data.
But what if, say, Sun release J2ee 5.0, and the first edition of the
metadata written by a third party is bad. Do you go to sun and say
'release a new version' for the sake of our repository?. Do you make up
your own version number, so sun are suddenly fielding support calls
related to j2ee-5.0.1? What happens when j2ee-5.0.1 itself ships?
Maybe the problem here is that we are using the metadata and the
artifact version as if they are the same thing. when really we want
j2ee5.0 described by metadata version 2006-11-08/stevel, the latter
probably with its own unique URL. But try adding that concept to a
library manager and see where you get.
Metadata is fallible. In some AI related areas (Agent oriented
programming), all facts are modelled as beliefs issued by an individual
at a specific time. Its ok for 2006-11-08/xavier to be different from
2006-11-08/steve, which can be different from 2006-11-09/steve. But
2006-11-08/steve must remain constant, and ideally, internally consistent.
