Hello internals,
after SQLite's commit ~16hours ago i was reminded that i have violated
vertain rules - not change something while in release process and not
changing api's of non experimental extensions.
I must admit i knew this before but i was in a conflict and i am still.
The conflict is i want consistency and there was a decision for studlyCaps.
To honor the rules more or less i first contacted the relevant ppl in private
and the majority agreed to the change (so i didn't rally wait to hear all).
Obviously i was a bit too hastily here. But i only started to workout the
change because SQLite's OO API was never released other than in RC1 - and
well that it was released like it was is of cause my failure as mentioned
already.
As you know my actings started a long discussion and now i am questioning:
Are we following our rules and decisions? And if so which rule/decision do
ppl want me to follow? The one i did which potentially hurts some article
writers? Or the other one which would lead to a revert and inconsistency?
For the moment my decision is to revert await the outcome of the ongoing
discussion. Asked as one of the maintainers i still want the studlyCaps for
consistency. Asked for PHP i also want the studlyCaps. It was a big mistake
not to change the api right after the decision - as i said my fault.
Sorry for the inconvenience
Best regards,
Marcus
The full diff to get SQLite in studlyCaps fashion can be downloaded here:
http://marcus-boerger.de/php/ext/sqlite/sqlite-oo-api-studlycaps.diff.txt
My take and a bit of a clarification for Andi. I wasn't criticizing you
personally, I was criticizing the Release Manager which happens to be you.
Admittedly the distinction is subtle. The RM's job is to heard cats.
You take input from everyone and make a decision on when to freeze and
when to release. After a freeze you fend off people who want to sneak in
changes that are not obvious bug fixes. If someone convinces you that a
bigger picture change is required, then you have a problem and I don't
think just quickly squeezing that change in and pushing out a new release
before too many people have downloaded the previous release is the right
solution to that problem because we need time to figure out the
ramifications of such a change. For example, how many PEAR packages might
we break with this? Are any of them perhaps even in the php5 tarball
itself?
On the Studlycaps issue my opinion is that it is a guideline and while it
would be nice to have consistency in the end it is ultimately up to the
extension authors to decide whether they wish to follow the guideline or
not. I have no plans on going back and breaking the few extensions I have
written that have OO APIs because I don't think aesthetic changes is worth
breaking BC over, but I will probably follow the guideline for new ones.
We could make the decision that we will not bundle any extension that
doesn't follow the guidelines although in this case that might not be a
good idea. I see 3 ways forward:
-
Stick with the freeze and deal with the inconsistency
-
Remove the freeze, convince Georg to make the change (if possible)
and make very sure people realize that RC1->RC2 is not just bug fixes -
Unbundle mysqli to pecl and let it evolve at its own pace and we can
include it in the standard tarball when everyone is happy with it
-Rasmus
Rasmus Lerdorf wrote:
ramifications of such a change. For example, how many PEAR packages might
we break with this? Are any of them perhaps even in the php5 tarball
itself?
I know this is just an example, but just to clarify:
PEAR is currently taking a bit of a wait and see approach with php5 for
obvious reasons. We are mainly looking at the BC breaks atm, so there
are really few packages that have moved to php5 only (afaik only
PHPUnit2 and SOAP2, which both havent reached a stable state yet).
Beyond that the biggest problem I can see PEAR facing with php5 are non
studlyCaps API's since then we have to wrap those API's even if we
actually just want to extend them, since our CS is studlyCaps.
Beyond that I want to make clear that I am in no position to vote on
anything on internals@ due to my lack of direct involvement with the php
source itself.
regards,
Lukas Smith
Rasmus Lerdorf wrote:
ramifications of such a change. For example, how many PEAR packages might
we break with this? Are any of them perhaps even in the php5 tarball
itself?I know this is just an example, but just to clarify:
PEAR is currently taking a bit of a wait and see approach with php5 for
obvious reasons. We are mainly looking at the BC breaks atm, so there
are really few packages that have moved to php5 only (afaik only
PHPUnit2 and SOAP2, which both havent reached a stable state yet).
Right, but we aren't just talking about PHP5-only PEAR packages here. We
bundle a couple of basic PEAR packages right in the PHP5 distribution
tarball so we have to be very careful with these and I think also with the
more common ones that people install.
-Rasmus
As you know my actings started a long discussion and now i am
questioning:
Are we following our rules and decisions? And if so which
rule/decision do
ppl want me to follow? The one i did which potentially hurts some
article
writers? Or the other one which would lead to a revert and
inconsistency?
Being concerned about BC before there is an actual release seems silly
to me. The whole of PHP5 could be accurately described as
'experimental' atm.
George
George Schlossnagle wrote:
Being concerned about BC before there is an actual release seems silly
to me. The whole of PHP5 could be accurately described as
'experimental' atm.
+INF
Everyone who is using PHP5 right now knows (or plausibly should know)
that it is experimental. Even the text accompanying the RC1 announcement
says that it is for "playing with" and is not recommended for
mission-critical use.
Making "BC"-breaking changes now affects a (comparative) few
experimenters. Leaving things as potentially confusing or inconsistent
affects the hundreds of thousands (millions?) of people who will use
PHP5 in the next 5 years.
David
At 04:30 PM 3/23/2004 -0800, Rasmus Lerdorf wrote:
On the Studlycaps issue my opinion is that it is a guideline and while it
would be nice to have consistency in the end it is ultimately up to the
extension authors to decide whether they wish to follow the guideline or
not. I have no plans on going back and breaking the few extensions I have
written that have OO APIs because I don't think aesthetic changes is worth
breaking BC over, but I will probably follow the guideline for new ones.We could make the decision that we will not bundle any extension that
doesn't follow the guidelines although in this case that might not be a
good idea. I see 3 ways forward:
Stick with the freeze and deal with the inconsistency
Remove the freeze, convince Georg to make the change (if possible)
and make very sure people realize that RC1->RC2 is not just bug fixesUnbundle mysqli to pecl and let it evolve at its own pace and we can
include it in the standard tarball when everyone is happy with it
Guys,
We all know that consistency problems in the past have been a pain in the
ass. I'm sure there have been hundreds of emails on internals@ about these
issues. All I'm saying is, why shoot ourselves in the foot so early in the
game especially as we mentioned studlyCaps in the CODING_STANDARDS. It
doesn't really matter if you like studlyCaps or prefer underscores;
consistency is the game.
I still think that the right thing to do is to do what's right (change to
studlyCaps) and release RC2 as soon as possible (whenever everyone is
ready). We will then restart a deep-freeze for new features and will
continue to stabilize PHP 5.
But as RM I can't go through every extension in PHP and make sure every
last place has been changed but extension authors also have to take
responsibility.
And yes, we'll need to change our articles on Zend.com and we'll have to
make changes in our PHP 5 book but I think PHP 5 is more important.
Andi