First off, thanks for an excellent summary Benson! Comments inline... On 2012-12-01 18:30, Benson Margulies wrote: > 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.
That's my recollection as well. > 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 agree that these objections should have been raised back when we discussed the architectural changes. > 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). My preference is 1 or perhaps 2, but I would rephrase it a bit as to not alienate users to try the 3.1.0 version. I would -1 any suggestion to start using the "beta" moniker again, at least for the changes made this far. 4 is out of the question in my mind. We've already had the discussion and back then we agreed that it would be wise to release 3.1.0 with SLF4J and the simple implementation. That should make logging output look like it always has. Some would say that's boring, but I'd say it's backwards compatible. All other changes such as "fancy" logging output would be deferred to a later release of Maven. Finally, unless there are overwhelming reasons against it (and I don't see any) the RM should be the one in the driver's seat. Jason has volunteered to be RM, which is great. Let him drive this through. -- Dennis Lundberg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
