On 03 Jan 2017, at 2:11 AM, William A Rowe Jr <[email protected]> wrote:
> So far, discussions are polarized on a single axis... > > East: Let's work on 3.0; whatever is going on in 2.4 won't distract me, I > won't spend time reviewing enhancements, because 3.0 is the goal. > > West: Let's keep the energy going on 2.4 enhancements, I won't spend time on > 3.0 usability because it isn't ready or necessary. > > There is a disconnect, because 'East' folks can't actually put up with the > breakage introduced by enhancements they can't review on 2.4, but all feel > responsible to keeping 2.4 usable to EOL. > > So I'd like to know, in light of a perpetual chain of (often build and/or > run-time breaking regression) enhancements, if there is support for a > 2.4.24.x release chain during the 3.0 transition? And support for potentially > 3x backports to 2.4.x, 2.4.24.x and 2.2.x, of really serious bug fixes? > > It's clear this project doesn't agree, so the question twists to how we agree > to disagree. Can you clarify the problem you’re trying to solve? v3.0 and v2.6 are just numbers. For modest changes, we move to v2.6. For a very large architecture change (for example, the addition of filters in v1.x to v2.x), we move to 3.0. Is there a very large architecture change planned by anybody? In my experience, things that felt initially like big changes have actually turned out to be rather modest changes that are still possible to backport to v2.4 without an issue. For this reason I haven’t seen a reason to push very hard for v2.6, never mind v3.0. Regards, Graham —
smime.p7s
Description: S/MIME cryptographic signature
