Hi internals,
The question is in the title :-)
As far as I know, most projects follow this convention: develop on the
master branch, then backport the fixes/features to older versions.
I had a discussion with another core dev who told me he did the opposite:
develop on PHP-5.5, then move the fix/feature up to the new branches (first
PHP-5.6, then master).
Is there a convention for php-src? Or is it "whatever the dev wants"?
--
Regards,
Florian Margaine
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 26/09/2014 13:29, Florian Margaine a écrit :
Hi internals,
The question is in the title :-)
As far as I know, most projects follow this convention: develop on
the master branch, then backport the fixes/features to older
versions.I had a discussion with another core dev who told me he did the
opposite: develop on PHP-5.5, then move the fix/feature up to the
new branches (first PHP-5.6, then master).
Yes this way.
Is there a convention for php-src? Or is it "whatever the dev
wants"?
See https://wiki.php.net/vcs/gitworkflow
Remi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlQlURwACgkQYUppBSnxahh+aQCffuNOmQJeSSAVjn9lCIx1YMl0
qk0AoOkHVzo7r85HxpxSDn1z98Y4ZVEc
=GRTv
-----END PGP SIGNATURE
On Fri, Sep 26, 2014 at 1:29 PM, Florian Margaine florian@margaine.com
wrote:
Hi internals,
The question is in the title :-)
As far as I know, most projects follow this convention: develop on the
master branch, then backport the fixes/features to older versions.I had a discussion with another core dev who told me he did the opposite:
develop on PHP-5.5, then move the fix/feature up to the new branches (first
PHP-5.6, then master).Is there a convention for php-src? Or is it "whatever the dev wants"?
--
Regards,
Florian Margaine
see https://wiki.php.net/vcs/gitworkflow
if a change affects multiple branch we commit it to the lowest possible
branch and merge it upwards.
there were a recent discussion about whether or not to change this, as the
current master (aka PHP7) has major changes which makes the merge
everything up strategy a lot more painful, but this discussion didn't
reached a consensus so there are no change in the old workflow.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
I see, thanks for the answer!
On Fri, Sep 26, 2014 at 1:29 PM, Florian Margaine florian@margaine.com
wrote:Hi internals,
The question is in the title :-)
As far as I know, most projects follow this convention: develop on the
master branch, then backport the fixes/features to older versions.I had a discussion with another core dev who told me he did the opposite:
develop on PHP-5.5, then move the fix/feature up to the new branches
(first
PHP-5.6, then master).Is there a convention for php-src? Or is it "whatever the dev wants"?
--
Regards,
Florian Margaine
see https://wiki.php.net/vcs/gitworkflow
if a change affects multiple branch we commit it to the lowest possible
branch and merge it upwards.
there were a recent discussion about whether or not to change this, as the
current master (aka PHP7) has major changes which makes the merge
everything up strategy a lot more painful, but this discussion didn't
reached a consensus so there are no change in the old workflow.--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
--
Regards,
Florian Margaine
On Fri, Sep 26, 2014 at 1:29 PM, Florian Margaine florian@margaine.com
wrote:The question is in the title :-)
As far as I know, most projects follow this convention: develop on
the master branch, then backport the fixes/features to older
versions.I had a discussion with another core dev who told me he did the
opposite: develop on PHP-5.5, then move the fix/feature up to the
new branches (first PHP-5.6, then master).Is there a convention for php-src? Or is it "whatever the dev
wants"?see https://wiki.php.net/vcs/gitworkflow if a change affects multiple
branch we commit it to the lowest possible branch and merge it
upwards. there were a recent discussion about whether or not to change
this, as the current master (aka PHP7) has major changes which makes
the merge everything up strategy a lot more painful, but this
discussion didn't reached a consensus so there are no change in the
old workflow.
But we really should fix this, as merging up is no fun right now.
cheers,
Derick
On Fri, Sep 26, 2014 at 1:29 PM, Florian Margaine florian@margaine.com
wrote:The question is in the title :-)
As far as I know, most projects follow this convention: develop on
the master branch, then backport the fixes/features to older
versions.I had a discussion with another core dev who told me he did the
opposite: develop on PHP-5.5, then move the fix/feature up to the
new branches (first PHP-5.6, then master).Is there a convention for php-src? Or is it "whatever the dev
wants"?see https://wiki.php.net/vcs/gitworkflow if a change affects multiple
branch we commit it to the lowest possible branch and merge it
upwards. there were a recent discussion about whether or not to change
this, as the current master (aka PHP7) has major changes which makes
the merge everything up strategy a lot more painful, but this
discussion didn't reached a consensus so there are no change in the
old workflow.But we really should fix this, as merging up is no fun right now.
cheers,
Derick
Hi,
IMO, there's no point in trying to merge between two fairly different
codebases. You could cherry-pick where appropriate, but this too will
become harder while PHP7 development progresses. In a natural way, the
two version trees become two separate efforts.
My $0.02.
Cheers,
Andrey.
Hi!
I had a discussion with another core dev who told me he did the opposite:
develop on PHP-5.5, then move the fix/feature up to the new branches (first
PHP-5.6, then master).
If you talking about developing new features, you can not develop on 5.5
because 5.5 is a stable release that is closed for new features. So you
should develop against master or, in rare cases you're sure your feature
is small and self-contained enough to be included in 5.6, then against 5.6.
If you're developing a bugfix, however, you should start with the
version the bugfix is applied to, which may be 5.5.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/