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]
