I could spend hours explaining why this statistic are meaningless, but I
think I should concentrate my effort proving you wrong on the
"battlefield" ;-)
I agree with you that we'll have a better overview only when we'll
merge, but we're in roadmap and we'll branch at most in 2 months. I
think we should try to branch already in december, and delay to jan 2007
*only* if we can be sure a missing critical feature will be ready by
that day, otherwise we should branch without that feature.
I won't bet the farm about the release date, but I'll work for that to
happen, and I expect the same from all other committers but you (as they
replied +1 to the next-major plans).
As we are in topic, and you started this "next 2.x release" that I hope
I should read as "2.3.1 vs next-minor" release, I would really
appreciate if you can give us some more detail on next-minor so we can
elaborate an shared opinion about 2.3.1 and next-minor and the need of
one with the regard to the other: "Consider it insurance".
First of all I described your next-minor effort this way:
-----
"next-minor":
- based on 2.3.0
- storage and config.xml compatibile with 2.3.0
- selective choice of what to backport from trunk.
- ETA: branch on Nov/Dec 2006, release on Dec/Jan 2007
-------
Can you confirm this is what you're working on? Otherwise make your
fixes ;-) .
The meaning of the "ETA" branch/release should be:
- features can be backported until the branch date
- between branch date and release date only bugfixes are backported and
bugs are fixed.
As we expect it to be out really soon, can you give us more details on
features you plan to backport?
Stefano
Noel J. Bergman wrote:
Norman,
I would follow Stefano..
First, I don't "follow." As I did with JAMES-592, I will keep my own
counsel. Second, this is not about Stefano, an eager, talented and
dedicated Committer. Nor is this about time, talent or coding ability.
Actually, we're way under the average for bugs per LOC.
However, I do not believe that we are going to copy trunk and have a stable
release a few months later. Why? A few facts:
SVN diff between 2.2 RC1 and final: 23304 lines
SVN diff between 2.3 RC1 and final: 15858 lines
SVN diff between 2.2 and 2.3 final: 63641 lines
SVN diff between 2.3.0 and trunk: 104,415 lines
Time from first 2.3 alpha to 2.3 release: 8 months
Time from the 2.3 RC1 to 2.3 release: 3 months
Of course, such statistical comparisons are fraught with danger for making
erroneous assumptions, and we have a big advantage that we haven't had
before: Bernd, the Mad Tester :-). But until we branch trunk, review all of
the changes from the stable code, and get serious about preparing a release,
any assertion that this release cycle will substantially differ from
previous ones is at best speculative.
If you really think its bad you should [help] fix it directly
If I really thought that trunk was a steaming pile of crap, I'd say so. As
I've said, I plan to work on trunk. But based upon the fact that there are
60% more lines of change between the current release and the source for
"next major" than between 2.2 and 2.3 -- and that doesn't include
handlerapi-v2 and any Mailet API changes -- I won't be betting the farm on a
release in (early) 2007. So while we work on the code from trunk, I plan to
manage nice, safe, incremental, changes based upon the stable code in v2.3.
Consider it insurance.
i really believe [trunk] at least such stable as 2.2.0 !
Number of issues fixed between 2.2 and 2.3: ~180
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
