How do you mean? What else is there to be concerned about WRT backward compat?
BTW, I don't think dropping the method entirely is a good course of action...but we do need to adjust the code to accommodate wagon providers that don't have it. I think the wagon API is probably stable enough to talk about putting out 1.0-final, and then proceed with 1.1-snap development, actually. I don't want to stop forward progress, I just want to make sure we don't get burned. If I caught this particular problem when trying to do a deploy using wagon-webdav, who else would see it? Let's just fix this, and think about how we can setup a couple simple tests for backward compat. I can whip up an integration test project in 3 minutes to test this one...I'll log the jira for it now. -john On 2/22/07, Joakim Erdfelt <[EMAIL PROTECTED]> wrote:
The Wagon.getProtocol() method could probably be dropped. But that won't address the bigger concern. Backwards compatibility. - Joakim John Casey wrote: > Also, to be clear, in the past I've broken things massively in Maven and > other places. Almost without fail, someone has tracked me down, and > waited > while I stopped everything I was doing, and fixed the problem...with > tests, > if possible. > > On 2/22/07, John Casey <[EMAIL PROTECTED]> wrote: >> >> Just to be clear - did I miss a volley of emails on these topics? >> >> -j >> >> On 2/22/07, Joakim Erdfelt <[EMAIL PROTECTED] > wrote: >> > >> > The changes to wagon are ... (just to make sure they show in john's >> > gmail account) >> > >> > 1) Timeouts >> > 2) Streaming Wagon >> > 3) Limited Transactions >> > >> > - Joakim >> > >> > John Casey wrote: >> > > Hi all, >> > > >> > > I have something to point out that I think the entire Maven >> > development >> > > community needs to hear. I've been doing a lot of work recently with >> > > Maven >> > > trunk, so I notice any (perhaps inevitable) instability that comes >> > > down the >> > > pike from dependency APIs. Recently, I've been having a LOT of >> trouble >> > in >> > > this area. >> > > >> > > Particularly in the Wagon API. It seems that a change was rolled >> into >> > > wagon-provider-api around the beginning of February that introduced >> > > some new >> > > methods into the Wagon interface. This is not in itself a problem, >> > even >> > > though the current code version is at 1.0-*beta*-3-SNAPSHOT. What >> > > causes an >> > > issue is the fact that these new methods are then assumed to be in >> > > place by >> > > the new DefaultWagonManager, effectively breaking that manager's >> > backward >> > > compatibility with previous releases of Wagon providers. >> > > >> > > I tracked all of this down over the course of the past few days, in >> > > between >> > > doing the things that I'm actually focused on doing. I can fix this >> > one >> > > problem by myself; I'm not pleading for help here. However, I cannot >> > > act as >> > > the gatekeeper for all APIs that get used in Maven trunk, to ensure >> > their >> > > stability and backward compatibility. I've been informed that there >> > > are many >> > > other such changes heading for Wagon...interestingly enough, a quick >> > > search >> > > of my GMail account doesn't turn up any discussion of these changes >> > > (unless >> > > it's buried in the deep past somewhere). >> > > >> > > I know that this email can look a bit hypocritical on its face, >> but I >> > > really >> > > do feel that we owe it to our user base to be a little more >> proactive >> > in >> > > ensuring backward compatibility than we have in the past. I >> understand >> > >> > > that >> > > many Maven developers are on various deadlines, but those >> deadlines do >> > > not >> > > originate in the Maven ASF project, and shouldn't cause undue >> harm to >> > the >> > > community or its code. I'm not trying to say we need to rigidly >> adopt >> > and >> > > conform to some process or other, but we each individually need to >> > take >> > > responsibility for discussing and testing any major changes we >> plan to >> > > put >> > > into Maven or its dependencies. >> > > >> > > IMHO, pushing new features into a beta API is irresponsible >> unless you >> > > can >> > > be ABSOLUTELY certain it will not impact backward compatibility. In >> > these >> > > cases, it is my understanding that the normal practice is to >> create a >> > > final >> > > release of the existing API, and then push these bigger changes into >> > the >> > > next version. >> > > >> > > If there's even a shadow of doubt about what effect a change will >> have >> > on >> > > the user community, we need to make a serious effort to start a >> > > discussion >> > > about it on this list. >> > > >> > > >> > > Regards, >> > > >> > > John >> > > >> > >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > For additional commands, e-mail: [EMAIL PROTECTED] >> > >> > >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
