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]
