On 11/8/06, Steve Loughran <[EMAIL PROTECTED]> wrote:
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. I agree with your concerns, and think this problem is really difficult to
address and deserves its own discussion, so I thank Gilles to have changed the mail subject :-) I've already thought a lot about that, but didn't reach any strong conclusion. What I think is really important is to be able to go back to the version of metadata used for a particular build, and using a tool like svn for that is something I've already considered and seen implemented by some customers. It works pretty well, the problem is that then you have to deal with metadata versions (as you explain Stephane) and this is not easy. Especially when several nodes in your dependency graph require different metadata revisions. What is even less easy is to maintain metadata for a public repository where you can't be sure the change is an improvement. It can be for one person but not for the other. That'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). The compatibility of all metadata revisions ensure that when you get the latest metadata revision (i.e. the current one on the repository) you are able to know its whole history. Thus you are able to resolve the dependency on the metadata revision 1 if you get the revision 2, the only thing that changes is that when you declare a dependency on all configurations, it actually means all configurations which existed in the metadata revision you indicate. This idea is the result of a few hours of thinking during my trip back from california last september, but I hadn't time to think more about it til now, nor to experiment with it. So I'm pretty sure you will find a lot of flaws to this idea, but it may be a good start for some kind of solution. Xavier
