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 > -----Original Message----- > From: Stephane Bailliez [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 08, 2006 2:15 PM > To: [email protected] > Subject: Re: future Ivy development > > Antoine Levy-Lambert wrote: > > Steve Loughran wrote: > > > >> > >> We need to recognise that infallibility-of-metadata is an > unrealistic > >> ideal and adapt to it. > >> > > I would more agree with Xavier, and believe that if the metadata in > > the POM or ivy.xml is wrong, there should be a new release > with a new > > version number. > > > > No. Because there is a world of difference between people > releasing a piece of software and people using it and dealing > with dependencies. > > What exists right now is what Steve describes. What will > happen is that when you will need component A you will add it > to the repo and add the dependency descriptor. Don't think a > minute you will get it right the first time. You won't. > > As for people describing the dependencies of their own piece > of software, just look at any Maven project and you will > realize that most of them are totally wrong as well, don't > care about scope or simply mixing development and release. > > > Otherwise, you can start tweaking everything everyday no ? > > > Not everyday. But this is why an online repo does not work to > me unless there is a revision system behind it instead of > binning stuff. > > You will change the metadata. If you want reproductability > (and you will want that) then version your repository. > >
