Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59227
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain schlueters.de from 217.114.211.66 cause and error)
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: Gustavo Lopes <glopes@nebm.ist.utl.pt>, internals@lists.php.net
In-Reply-To: <CAGa2bXbMr4+xfwqK+D71MZHfQ1XPOdD9tRTCuRdOunwr1uT3MQ@mail.gmail.com>
References:
	 <CAGa2bXZP0GfH2_D8yOtj-LvbM2tQFQ49K4RwB8max9v4cCpTxg@mail.gmail.com>
	 <op.wby3gkjqidpuyk@slws007.slhq.int>
	 <CAGa2bXbMr4+xfwqK+D71MZHfQ1XPOdD9tRTCuRdOunwr1uT3MQ@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Date: Fri, 30 Mar 2012 11:40:15 +0200
Message-ID: <1333100415.2620.220.camel@guybrush>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Merge from 5.3 and/or 5.4. What's the current policy?
From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)

On Fri, 2012-03-30 at 17:22 +0900, Yasuo Ohgaki wrote:
> Hi,
> 
> Bug fix can be merged upwards. However,
> Are we free to merge feature changes?
> 
> Adding new module constant is new feature.
> I certainly would like to have it on 5.4 and it's
> probably OK for 5.4, but how about 5.3?
> So I'm asking procedure before commit.

Either be brave and make a decision yourself or ask for a specific case.

For 5.3 the situation is that only bug fixes should go in. There are two
reasons for that:

      * Backwards compatibility. Users must be able to upgrade from
        5.3.x to 5.3.(x+1) without thinking about it. Everything must
        run as before.
      * Users should have as many reasons as possible to upgrade to a
        newer version.

Now there's of course the old question "what's a bug and what's a
feature?" which is hard to answer in some cases.
    http://blog.zugschlus.de/uploads/bug-feature.jpg

Adding a constant can brings two potential compatibility issues. One is
that it might require a newer library version and is breaking
compatibility there and it might conflict with a name used in a user
application. I think on the first one we are quite safe and the second
one is also low risk ... and well _not_ adding the constant is a bit
ridiculous ;-)


All that aside: Two comments on the "feature design":

     A. A function pg_version() exists, having both, a function
        pg_version() and a constant PG_VERSION, which do slightly
        different things is confusing.
     B. All existing constants use PGSQL_* as prefix.

 -> Maybe a different name like PGSQL_CLIENT_VERSION is better.

johannes