Hi,
it is sad to see that the discussion went in the direction it went, but I'm
glad to have missed that being away all day and at the end of it realizing my
mail server messed up. Please lets get the tone down and discuss factually!
I would like to turn back to the point I was depicting in my first mail - the
current stuff destined (including the bug fix for the sym table issue ofc) into
the 7.NEXT looks pretty much like a set of fixes for a patch version. It is
enough to go through the NEWS of 5.5 or 5.6 and compare to realize that. In
aforementioned NEWS files, several bugs can be evaluated even as more critical
as the subject caused the discussion. An accusation that the intention to
deliver this as GA has the purpose of something bad has therefore just no
objective base. In opposite - looking like a patch release is a testimony that
7.0 is ripe enough to enter the routine life cycle.
Today, we have a set of patches that can deliver a stable 7.0.0 to the today's
knowledge (remember also 5.x NEWS files in conjunction with this). I probably
just repeat what I was telling - any known app compatible with 7.0.0 today has
the tests green today.
To comply with the above and the definition of stable. Now, with
7.0.0. The gap between 5 and 7 is big, the number of
ported apps is small, same with the number of developers using it. How
do we get the wheel to spin? Please think strategically. How do we get the
7.0.0 GA to have the gap to be the same as between some adjacent PHP5 minor
releases?
Short - one can delay. There is a group of people who wants it to be done. What
does that mean? That means, less usage, less testing, slower bug discovery.
Even shorter - one can release. What does that mean? That means that we are on
the track, more apps are getting ported, more people use it, more bugs we fix -
we are stable.
Just to remind - the RC7 was caused but the exact reason that it were
impossible and extremely bad to deliver an untested lot of various and
partially bad issues. And that was suitable. That's why also other two weeks
was taken. It is quite pointless to have a one week RC, because the feedback on
that is negligible and consequently no real bugs are catched. It doesn't comply
with the expressed intention to validate the bug fix. Now, it is of course the
matter of the definition, but issuing one more RC for the bugs that are don't
even stand near the cause of the RC7 doesn't sound like an appropriate action.
Either the bugs are heavy weight and the fixes need to be properly tested, or
they are not. Except one turns back to the thesis that there should be no bugs.
So in the end, a solution is wanted. I don't think any opinion is allowed to be
ignored for such a topic. So options
a) release on 26th including all known bug fixes
b) do RC8, assume there are no bugs, so target 10th for RTM
c) do RC8, release on 3rd, expect there are no bugs come in
d) continue issuing release candidates till it's stable enough (needs
definition of stable and probably an RFC)
I would really ask to reach a consent on either a) or c). IMO, the options b)
and d) are the direct road to curbing 7.0.0. There is no hurry to release just
to release, but it is definitely harmful to slow down the rise.
Thanks
Anatol
