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] > >
