@Benson >No one, as far as I recall, objected, but perhaps my memory is selective. just for the record: I did cast -1 on the commit and explained my objections ...
I obviously don't like it but I wont 'veto' it as those technical questions are simply majority votes. And there are quite some devs who like it it seems... @Kristian > As long as the reworked plugins still work > with older maven versions I think we're in the clear. The new plugins will only work with maven-3.1++ as they will not find any slf4j logger on older versions. What I'm more concerned is that old projects which perfectly work with mvn-2.2.0, mvn-2.2.1, mvn-3.0.3, mvn-3.0.4, etc don't work anymore with mvn-3.1. This will not be the case very often but it will happen. Of course nothing which cannot get fixed. Well, the LocationAwareLogger incompatibility might be a blow sometimes... LieGrue, strub ----- Original Message ----- > From: Kristian Rosenvold <[email protected]> > To: Maven Developers List <[email protected]> > Cc: > Sent: Saturday, December 1, 2012 6:51 PM > Subject: Re: 3.1.0 decision making > > Although I generally stay away from any kind of logging-discussion > (and logging in general), I'd like to add my 0.5 NOK: > > The version number *is* 3.1 due to this slight compatibility change; > we need to make this clear in release announcements to control > community expectations. > > If a few plugins need reworking to stay compatible I think that's ok; > it's the price of progress. As long as the reworked plugins still work > with older maven versions I think we're in the clear. > > Furthermore I do not think maven needs to be a "generalized execution > environment" that imposes no constraints on plugins. This is IMO where > maven differs from something like an EJB container. > > I say 1 or 4 are the only viable options, and I'm all for 1. > > Kristian > > 2012/12/1 Benson Ma rgulies <[email protected]>: >> I'm writing this to move the discussion about our next release off of >> a VOTE thread, where I don't think it belongs. >> >> Let me make a little historical summary. Jason and others made a >> series of significant changes to the core internals, including changes >> to logging that some users of some plugins may view as incompatible. >> >> No one vetoed those changes, though there's been plenty of discussion. >> >> Jason sent email announcing his intention to RM a 3.1.0. >> >> No one, as far as I recall, objected, but perhaps my memory is selective. >> >> Jason put 3.1.0 out for a vote. >> >> Two sets of objections surfaced: >> >> o The objection of those who are not happy with the logging change. >> o The objection of those who think it a problem to create a 3.x >> release with only internal improvements, but no user-visible features. >> (Footnote: fixing all the memory leakage is a big user-visible >> 'feature' for M2E and other embedded users.) >> >> I wish that people had raised these objections at the time that the >> release was proposed, but the main matter at hand is to decide what to >> do about them. >> >> I offer some options: >> >> 1: proceed 'as-is'. Some people won't love 3.1 because it > offers them >> nothing they care about, and others may object to the results of the >> logging change. So they will hang back until we make further progress. >> That's fine. If someone hits a bad-enough bug, we can even make a >> 3.0.5. >> >> 2: proceed 'as-is', but announce and release-note the release as >> something like: "Release 3.1.0 is intended for use by plugin >> developers and advanced users to test out and exercise significant >> architectural changes. Others may prefer to stick to 3.0.4 until we go >> through a cycle of collecting feedback and push out one or more 3.1.x >> releases". >> >> 3: Same idea as (2), but label it 3.1-beta1. >> >> 4: Stop in our tracks until we resolve these questions. >> >> I'm opposed to option 4. I'm particularly opposed to the view that > a >> 3.1 release must have goodies for end users, like fancy colors. I've >> no objection to (or use for) colors, but I feel quite strongly that >> it's legitimate to ship a release that pushes out architecture even if >> it has no instant gratification for end users. >> >> As for the logging argument, I'd rather take (2) or (3) than (4). >> >> --------------------------------------------------------------------- >> 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
