[PHP-DEV] Merge from 5.3 and/or 5.4. What's the current policy?

Hi,

Since the git work flow in the wiki requires to apply patch to
lowest possible branch, then merge upwards.

This changes old work flow, commit trunk, then merge to
release.

I've committed simple build problem fix to all branches, I think
release masters don't care such merge. However, how about
feature changes?

I have simple patch for

Request #47570 libpq's PG_VERSION should be exported to userland
https://bugs.php.net/bug.php?id=47570

This is simple change, but it's new feature. (I added 2 new module
constants for PG_VERSION, PG_VERSION_STR)

Question is "What's the standard work flow for new features?"

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On Fri, 30 Mar 2012 02:59:29 +0200, Yasuo Ohgaki <[email protected]>
wrote:

> Since the git work flow in the wiki requires to apply patch to
> lowest possible branch, then merge upwards.
>
> This changes old work flow, commit trunk, then merge to
> release.
>
> I've committed simple build problem fix to all branches, I think
> release masters don't care such merge. However, how about
> feature changes?
>
> I have simple patch for
>
> Request #47570 libpq's PG_VERSION should be exported to userland
> https://bugs.php.net/bug.php?id=47570
>
> This is simple change, but it's new feature. (I added 2 new module
> constants for PG_VERSION, PG_VERSION_STR)
>
> Question is "What's the standard work flow for new features?"
>

I don't see how this is any different. "Lowest possible branch" doesn't
necessarily mean 5.3. It can mean 5.4 or master.

If the feature is not appropriate for 5.3, but it is for 5.4 and master,
commit it to 5.4 and merge 5.4 into master. Or it can be appropriate just
for master, in which case there's no merge into other branches. This is
the most common scenario -- when a commit is applicable to one branch and
all other more recent ones.

The problem with the current workflow is only when you have something
specific to a lower branch, which is not applicable to upper branches
because the code base has diverged. You still have to merge upwards in
those situations and resolve the likely conflict (typically with the
"ours" strategy).

--
Gustavo Lopes

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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.

Before git, we just commit new feature/changes
to trunk and we could think/argue about merge
later. Now we need to think/argue about merge,
then commit.

We need some guidelines for feature changes,
if we are going to keep "merge upward" policy.

Anyway, RM of 5.3/5.4 are okay to add module
constants to pgsql? If there is no objection, I'll
commit the change and updates docs.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

2012/3/30 Gustavo Lopes <[email protected]>:
> On Fri, 30 Mar 2012 02:59:29 +0200, Yasuo Ohgaki <[email protected]> wrote:
>
>> Since the git work flow in the wiki requires to apply patch to
>> lowest possible  branch, then merge upwards.
>>
>> This changes old work flow, commit trunk, then merge to
>> release.
>>
>> I've committed simple build problem fix to all branches, I think
>> release masters don't care such merge. However, how about
>> feature changes?
>>
>> I have simple patch for
>>
>> Request #47570  libpq's PG_VERSION should be exported to userland
>> https://bugs.php.net/bug.php?id=47570
>>
>> This is simple change, but it's new feature. (I added 2 new module
>> constants for PG_VERSION, PG_VERSION_STR)
>>
>> Question is "What's the standard work flow for new features?"
>>
>
> I don't see how this is any different. "Lowest possible branch" doesn't
> necessarily mean 5.3. It can mean 5.4 or master.
>
> If the feature is not appropriate for 5.3, but it is for 5.4 and master,
> commit it to 5.4 and merge 5.4 into master. Or it can be appropriate just
> for master, in which case there's no merge into other branches. This is the
> most common scenario -- when a commit is applicable to one branch and all
> other more recent ones.
>
> The problem with the current workflow is only when you have something
> specific to a lower branch, which is not applicable to upper branches
> because the code base has diverged. You still have to merge upwards in those
> situations and resolve the likely conflict (typically with the "ours"
> strategy).
>
> --
> Gustavo Lopes

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

hi,

On Fri, Mar 30, 2012 at 10:22 AM, Yasuo Ohgaki <[email protected]> wrote:

> Bug fix can be merged upwards. However,
> Are we free to merge feature changes?


Generally speaking, no.

> Adding new module constant is new feature.

Not necessary, for example in Curl or openssl, many constants addition
do not change the implementation per se. But it has to be discussed
from a case by case basis.

> Before git, we just commit new feature/changes
> to trunk and we could think/argue about merge
> later. Now we need to think/argue about merge,
> then commit.

Right, and that's actually very good. The commit first then try to
discuss is finally over.

> We need some guidelines for feature changes,
> if we are going to keep "merge upward" policy.

> Anyway, RM of 5.3/5.4 are okay to add module
> constants to pgsql? If there is no objection, I'll
> commit the change and updates docs.

RMs apply the developers decisions, in general. So please post your
proposals to the list, CCing them :)

Cheers,
--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Hi

2012/3/30 Pierre Joye <[email protected]>:
> hi,
>
> On Fri, Mar 30, 2012 at 10:22 AM, Yasuo Ohgaki <[email protected]> wrote:
>
>> Bug fix can be merged upwards. However,
>> Are we free to merge feature changes?
>
>
> Generally speaking, no.

I thought so.

>
>> Adding new module constant is new feature.
>
> Not necessary, for example in Curl or openssl, many constants addition
> do not change the implementation per se. But it has to be discussed
> from a case by case basis.
>
>> Before git, we just commit new feature/changes
>> to trunk and we could think/argue about merge
>> later. Now we need to think/argue about merge,
>> then commit.
>
> Right, and that's actually very good. The commit first then try to
> discuss is finally over.

For large changes, discussing first is good.
For small changes like this, it may be too much.

>
>> We need some guidelines for feature changes,
>> if we are going to keep "merge upward" policy.
>
>> Anyway, RM of 5.3/5.4 are okay to add module
>> constants to pgsql? If there is no objection, I'll
>> commit the change and updates docs.
>
> RMs apply the developers decisions, in general. So please post your
> proposals to the list, CCing them :)


https://gist.github.com/2250214

The change is simple one.
Just making constants available defined in pg-config.h

The only reason why I've made this thread for this simple
change is "merge upward" policy.

Someone suggested gitflow, the flow would be better for
faster development.

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php