Hi internals,
Based on previous discussions, it appears that our current plan is to
release PHP 8.0 after PHP 7.4. Normally we only branch off versions once
they reach beta stage, which means the PHP-7.4 branch will only be created
around summer 2019.
I would like to propose to branch off PHP-7.4 earlier this time and start
working on PHP 8.0 in the master branch. This will allow people to start
working on changes that are not suitable for PHP 7.4 (due to either
significant internal ABI breakage, or userland breakage).
Because each new branch introduces a lot of merge overhead for
contributors, I would further propose that merges should only go up to
PHP-7.4, while merges into master (PHP 8) will be performed occasionally,
on an as-needed basis, by the people working on it.
Regards,
Nikita
Based on previous discussions, it appears that our current plan is to
release PHP 8.0 after PHP 7.4. Normally we only branch off versions once
they reach beta stage, which means the PHP-7.4 branch will only be created
around summer 2019.I would like to propose to branch off PHP-7.4 earlier this time and start
working on PHP 8.0 in the master branch. This will allow people to start
working on changes that are not suitable for PHP 7.4 (due to either
significant internal ABI breakage, or userland breakage).Because each new branch introduces a lot of merge overhead for
contributors, I would further propose that merges should only go up to
PHP-7.4, while merges into master (PHP 8) will be performed occasionally,
on an as-needed basis, by the people working on it.
You seem to be describing a feature branch called "master". How about
we do what we did with 7.0 which is to say we had php-ng on a feature
branch which was eventually merged to master, and had the 64bit branch
which was similarly merged in at the appropriate time.
The one thing which didn't work well at the time was that php-ng was
partially done in the dark which made the 64bit branch's merge less
optimal. But as long as we're doing our feature branch development in
the open, this shouldn't be a problem.
-Sara
Based on previous discussions, it appears that our current plan is to
release PHP 8.0 after PHP 7.4. Normally we only branch off versions once
they reach beta stage, which means the PHP-7.4 branch will only be created
around summer 2019.I would like to propose to branch off PHP-7.4 earlier this time and start
working on PHP 8.0 in the master branch. This will allow people to start
working on changes that are not suitable for PHP 7.4 (due to either
significant internal ABI breakage, or userland breakage).Because each new branch introduces a lot of merge overhead for
contributors, I would further propose that merges should only go up to
PHP-7.4, while merges into master (PHP 8) will be performed occasionally,
on an as-needed basis, by the people working on it.
Have you considered having a separate PHP-8 branch, which can be rebased
onto master from time to time, and eventually be merged into master
(basically, treating the PHP-8 branch as a big feature branch)?
--
Christoph M. Becker
On Thu, Nov 15, 2018 at 5:07 PM Christoph M. Becker cmbecker69@gmx.de
wrote:
Based on previous discussions, it appears that our current plan is to
release PHP 8.0 after PHP 7.4. Normally we only branch off versions once
they reach beta stage, which means the PHP-7.4 branch will only be
created
around summer 2019.I would like to propose to branch off PHP-7.4 earlier this time and start
working on PHP 8.0 in the master branch. This will allow people to start
working on changes that are not suitable for PHP 7.4 (due to either
significant internal ABI breakage, or userland breakage).Because each new branch introduces a lot of merge overhead for
contributors, I would further propose that merges should only go up to
PHP-7.4, while merges into master (PHP 8) will be performed occasionally,
on an as-needed basis, by the people working on it.Have you considered having a separate PHP-8 branch, which can be rebased
onto master from time to time, and eventually be merged into master
(basically, treating the PHP-8 branch as a big feature branch)?
First, I think that continuously merging the level of changes we have in
store for PHP 8 on an ongoing basis from a branch into master - while
master is a moving target - would be a pretty big headache. That's why I
think there's sense to PHP 8 being the master branch, where most
development would go towards.
However, I think that if PHP 8 is on master - it should become the
responsibility of people who introduce patches for 7.4 - to also ensure
that they work with 8 (master). If PHP 8 will be in a branch, that's much
less likely to happen. Given the complexity and effort of 8, I think we
could use some shared responsibility here, instead of putting the burden on
the few working on the PHP 8 magic.
Another option, by the way, would be ditching 7.4 altogether and focusing
our efforts on 8.0 right away. It does mean people won't get typed
properties in 2019, but it will mean they'll likely get PHP 8 sooner.
Zeev
On Thu, Nov 15, 2018 at 5:07 PM Christoph M. Becker cmbecker69@gmx.de
wrote:Based on previous discussions, it appears that our current plan is to
release PHP 8.0 after PHP 7.4. Normally we only branch off versions once
they reach beta stage, which means the PHP-7.4 branch will only be
created
around summer 2019.I would like to propose to branch off PHP-7.4 earlier this time and
start
working on PHP 8.0 in the master branch. This will allow people to start
working on changes that are not suitable for PHP 7.4 (due to either
significant internal ABI breakage, or userland breakage).Because each new branch introduces a lot of merge overhead for
contributors, I would further propose that merges should only go up to
PHP-7.4, while merges into master (PHP 8) will be performed
occasionally,
on an as-needed basis, by the people working on it.Have you considered having a separate PHP-8 branch, which can be rebased
onto master from time to time, and eventually be merged into master
(basically, treating the PHP-8 branch as a big feature branch)?First, I think that continuously merging the level of changes we have in
store for PHP 8 on an ongoing basis from a branch into master - while
master is a moving target - would be a pretty big headache. That's why I
think there's sense to PHP 8 being the master branch, where most
development would go towards.However, I think that if PHP 8 is on master - it should become the
responsibility of people who introduce patches for 7.4 - to also ensure
that they work with 8 (master). If PHP 8 will be in a branch, that's much
less likely to happen. Given the complexity and effort of 8, I think we
could use some shared responsibility here, instead of putting the burden on
the few working on the PHP 8 magic.
If people are introducing major changes (e.g. when typed properties lands)
it's reasonable to expect that they will also carry out the merge to the
PHP 8 branch, as such merges are often tricky and require domain knowledge.
What I'm mainly suggesting is that we do not merge every single commit into
the PHP 8 branch, as is our current practice. Depending on where you land
your change, you currently already have to merge across PHP-7.1, PHP-7.2,
PHP-7.3 and master, which is a pretty big hassle. I would rather not add
one more branch to that list.
I really don't think that merging into the PHP 8 branch is going to be an
issue, though we can always reconsider the merge procedure if that turns
out to be wrong.
Another option, by the way, would be ditching 7.4 altogether and focusing
our efforts on 8.0 right away. It does mean people won't get typed
properties in 2019, but it will mean they'll likely get PHP 8 sooner.
For me PHP 7.4 is more important for deprecations than typed properties. If
we don't have a PHP 7.4 release, we end up in the same situation as PHP 7:
We have an opportunity to introduce a degree of BC breakage, but the last
opportunity to introduce deprecations has already sailed by the time the
decision is made. Unless we are fine with removing functionality without
prior deprecation, I think we need the PHP 7.4 release.
Nikita
On Thu, Nov 15, 2018 at 5:07 PM Christoph M. Becker cmbecker69@gmx.de
wrote:Based on previous discussions, it appears that our current plan is to
release PHP 8.0 after PHP 7.4. Normally we only branch off versions once
they reach beta stage, which means the PHP-7.4 branch will only be
created
around summer 2019.I would like to propose to branch off PHP-7.4 earlier this time and
start
working on PHP 8.0 in the master branch. This will allow people to start
working on changes that are not suitable for PHP 7.4 (due to either
significant internal ABI breakage, or userland breakage).Because each new branch introduces a lot of merge overhead for
contributors, I would further propose that merges should only go up to
PHP-7.4, while merges into master (PHP 8) will be performed
occasionally,
on an as-needed basis, by the people working on it.Have you considered having a separate PHP-8 branch, which can be rebased
onto master from time to time, and eventually be merged into master
(basically, treating the PHP-8 branch as a big feature branch)?First, I think that continuously merging the level of changes we have in
store for PHP 8 on an ongoing basis from a branch into master - while
master is a moving target - would be a pretty big headache. That's why I
think there's sense to PHP 8 being the master branch, where most
development would go towards.However, I think that if PHP 8 is on master - it should become the
responsibility of people who introduce patches for 7.4 - to also ensure
that they work with 8 (master). If PHP 8 will be in a branch, that's much
less likely to happen. Given the complexity and effort of 8, I think we
could use some shared responsibility here, instead of putting the burden on
the few working on the PHP 8 magic.If people are introducing major changes (e.g. when typed properties lands)
it's reasonable to expect that they will also carry out the merge to the
PHP 8 branch, as such merges are often tricky and require domain knowledge.
What I'm mainly suggesting is that we do not merge every single commit into
the PHP 8 branch, as is our current practice. Depending on where you land
your change, you currently already have to merge across PHP-7.1, PHP-7.2,
PHP-7.3 and master, which is a pretty big hassle. I would rather not add
one more branch to that list.I really don't think that merging into the PHP 8 branch is going to be an
issue, though we can always reconsider the merge procedure if that turns
out to be wrong.Another option, by the way, would be ditching 7.4 altogether and focusing
our efforts on 8.0 right away. It does mean people won't get typed
properties in 2019, but it will mean they'll likely get PHP 8 sooner.For me PHP 7.4 is more important for deprecations than typed properties. If
we don't have a PHP 7.4 release, we end up in the same situation as PHP 7:
We have an opportunity to introduce a degree of BC breakage, but the last
opportunity to introduce deprecations has already sailed by the time the
decision is made. Unless we are fine with removing functionality without
prior deprecation, I think we need the PHP 7.4 release.Nikita
I strongly agree on 7.4 being necessary.
I think no matter how we do the branching we will have some headache;
I will support whatever the most active committers and maintainers
decide is best.
On Thu, Nov 15, 2018 at 5:07 PM Christoph M. Becker cmbecker69@gmx.de
wrote:Because each new branch introduces a lot of merge overhead for
contributors, I would further propose that merges should only go up to
PHP-7.4, while merges into master (PHP 8) will be performed occasionally,
on an as-needed basis, by the people working on it.Have you considered having a separate PHP-8 branch, which can be rebased
onto master from time to time, and eventually be merged into master
(basically, treating the PHP-8 branch as a big feature branch)?First, I think that continuously merging the level of changes we have in
store for PHP 8 on an ongoing basis from a branch into master - while
master is a moving target - would be a pretty big headache. That's why I
think there's sense to PHP 8 being the master branch, where most
development would go towards.However, I think that if PHP 8 is on master - it should become the
responsibility of people who introduce patches for 7.4 - to also ensure
that they work with 8 (master). If PHP 8 will be in a branch, that's much
less likely to happen. Given the complexity and effort of 8, I think we
could use some shared responsibility here, instead of putting the burden on
the few working on the PHP 8 magic.
Actually, I'm fine with this. What I wouldn't like is that we have a
master which is not always merged into, since that likely causes
headaches for those willing to merge their changes from PHP-7.4 upwards,
and maybe also for those testing on “nightlies”.
Another option, by the way, would be ditching 7.4 altogether and focusing
our efforts on 8.0 right away. It does mean people won't get typed
properties in 2019, but it will mean they'll likely get PHP 8 sooner.
Yeah, might still be an option, but I would have preferred to already
have had an RFC for this. :)
--
Christoph M. Becker
First, I think that continuously merging the level of changes we have in
store for PHP 8 on an ongoing basis from a branch into master - while
master is a moving target - would be a pretty big headache. That's why I
think there's sense to PHP 8 being the master branch, where most
development would go towards.
Okay, that's a fair argument against the feature branch route.
However, I think that if PHP 8 is on master - it should become the
responsibility of people who introduce patches for 7.4 - to also ensure
that they work with 8 (master). If PHP 8 will be in a branch, that's much
less likely to happen. Given the complexity and effort of 8, I think we
could use some shared responsibility here, instead of putting the burden on
the few working on the PHP 8 magic.
Yes to shared responsibility, no to failing to merge changes to 7.4 up
to master. Either we will want that change, in case it should be
merged immediately rather than kicking the can down the road, or it
does not belong on master and we should null-merge it like we would
any other bugfix today. We must not put ourselves in the position of
7.4 being ahead of master. Period.
Another option, by the way, would be ditching 7.4 altogether and focusing
our efforts on 8.0 right away. It does mean people won't get typed
properties in 2019, but it will mean they'll likely get PHP 8 sooner.
As tempting as that may be, I think this would be incredibly
irresponsible to PHP users. 7.4 is a necessity on the grounds of
having a deprecations release alone, nevermind the availability of new
features.
TLDR;
I'm willing to embrace an early fork for 7.4, but we treat it like a
normal fork, not a special-psuedo-feature-branch. I also strongly
oppose dropping 7.4 as a release.
-Sara
First, I think that continuously merging the level of changes we have in
store for PHP 8 on an ongoing basis from a branch into master - while
master is a moving target - would be a pretty big headache. That's why
I
think there's sense to PHP 8 being the master branch, where most
development would go towards.Okay, that's a fair argument against the feature branch route.
However, I think that if PHP 8 is on master - it should become the
responsibility of people who introduce patches for 7.4 - to also ensure
that they work with 8 (master). If PHP 8 will be in a branch, that's
much
less likely to happen. Given the complexity and effort of 8, I think we
could use some shared responsibility here, instead of putting the burden
on
the few working on the PHP 8 magic.Yes to shared responsibility, no to failing to merge changes to 7.4 up
to master. Either we will want that change, in case it should be
merged immediately rather than kicking the can down the road, or it
does not belong on master and we should null-merge it like we would
any other bugfix today. We must not put ourselves in the position of
7.4 being ahead of master. Period.Another option, by the way, would be ditching 7.4 altogether and focusing
our efforts on 8.0 right away. It does mean people won't get typed
properties in 2019, but it will mean they'll likely get PHP 8 sooner.As tempting as that may be, I think this would be incredibly
irresponsible to PHP users. 7.4 is a necessity on the grounds of
having a deprecations release alone, nevermind the availability of new
features.TLDR;
I'm willing to embrace an early fork for 7.4, but we treat it like a
normal fork, not a special-psuedo-feature-branch. I also strongly
oppose dropping 7.4 as a release.-Sara
I'm not sure how we got to 7.4 becoming a feature branch. The options as I
see it are:
- Fork PHP-7.4, make master PHP 8 and merge all commits up to master.
Likely means that many commits that could target 7.4 will be going into
master, because we really can't be bothered. - Keep PHP 7.4 on master and feature branch PHP-8.0-Preview, without
merging every commit. Everything that's not PHP 8 specific continues to
land on master and targets PHP 7.4.
Both are sensible options, it depends on whether we want to focus
development on PHP 8.0 (first option) or PHP 7.4 (second option) at this
point in time. My vote goes to 2) for now. We should have a place for PHP 8
changes now, but with the release still being at least two years away I
don't think it should become our primary development branch just yet.
Nikita
First, I think that continuously merging the level of changes we have in
store for PHP 8 on an ongoing basis from a branch into master - while
master is a moving target - would be a pretty big headache. That's why
I
think there's sense to PHP 8 being the master branch, where most
development would go towards.Okay, that's a fair argument against the feature branch route.
However, I think that if PHP 8 is on master - it should become the
responsibility of people who introduce patches for 7.4 - to also ensure
that they work with 8 (master). If PHP 8 will be in a branch, that's
much
less likely to happen. Given the complexity and effort of 8, I think we
could use some shared responsibility here, instead of putting the burden
on
the few working on the PHP 8 magic.Yes to shared responsibility, no to failing to merge changes to 7.4 up
to master. Either we will want that change, in case it should be
merged immediately rather than kicking the can down the road, or it
does not belong on master and we should null-merge it like we would
any other bugfix today. We must not put ourselves in the position of
7.4 being ahead of master. Period.Another option, by the way, would be ditching 7.4 altogether and focusing
our efforts on 8.0 right away. It does mean people won't get typed
properties in 2019, but it will mean they'll likely get PHP 8 sooner.As tempting as that may be, I think this would be incredibly
irresponsible to PHP users. 7.4 is a necessity on the grounds of
having a deprecations release alone, nevermind the availability of new
features.TLDR;
I'm willing to embrace an early fork for 7.4, but we treat it like a
normal fork, not a special-psuedo-feature-branch. I also strongly
oppose dropping 7.4 as a release.-Sara
I'm not sure how we got to 7.4 becoming a feature branch. The options as I
see it are:
- Fork PHP-7.4, make master PHP 8 and merge all commits up to master.
Likely means that many commits that could target 7.4 will be going into
master, because we really can't be bothered.- Keep PHP 7.4 on master and feature branch PHP-8.0-Preview, without
merging every commit. Everything that's not PHP 8 specific continues to
land on master and targets PHP 7.4.Both are sensible options, it depends on whether we want to focus
development on PHP 8.0 (first option) or PHP 7.4 (second option) at this
point in time. My vote goes to 2) for now. We should have a place for PHP 8
changes now, but with the release still being at least two years away I
don't think it should become our primary development branch just yet.
hi,
After all, and despite of the first proposal was mine, now I think, we
should start from the second option.
-
in the near future (by mid January) fork PHP-8 and start active
development there. Keep PHP-7.4 development in master, and don't require
committers to merge into PHP-8, but restrict PHP-7.4 for minor changes
or features that won't significantly affect PHP-8 branch. -
in May/June move master into PHP-7.4, make PHP-8 to be master and
require committers to work on master and backport changes (according to
usual PHP/GIT workflow).
To target typed-properties or other significant changes to PHP-7.4, it's
better to commit them before PHP-8 branching.
Thanks. Dmitry.
in the near future (by mid January) fork PHP-8 and start active
development there. Keep PHP-7.4 development in master, and don't require
committers to merge into PHP-8, but restrict PHP-7.4 for minor changes
or features that won't significantly affect PHP-8 branch.in May/June move master into PHP-7.4, make PHP-8 to be master and
require committers to work on master and backport changes (according to
usual PHP/GIT workflow).
If fixes are not required to be merged to PHP-8, then how do we ensure
that those fixes (especially the security ones) will still be in
effect when 8.0 is released?
To target typed-properties or other significant changes to PHP-7.4, it's
better to commit them before PHP-8 branching.
How will that impact deprecations? Are we calling those "not
significant"? I'd actually say yeah since they tend to take the form
of a few lines of "stop doing this". I do worry about our ability to
pull a deprecations list together by January though.
FTR; This feels like the worst available option. It's basically just
early branching with bad names. I'd much sooner branch PHP-7.4 in
January and have that be it.
-Sara
First, I think that continuously merging the level of changes we have in
store for PHP 8 on an ongoing basis from a branch into master - while
master is a moving target - would be a pretty big headache. That's why
I
think there's sense to PHP 8 being the master branch, where most
development would go towards.Okay, that's a fair argument against the feature branch route.
However, I think that if PHP 8 is on master - it should become the
responsibility of people who introduce patches for 7.4 - to also ensure
that they work with 8 (master). If PHP 8 will be in a branch, that's
much
less likely to happen. Given the complexity and effort of 8, I think we
could use some shared responsibility here, instead of putting the burden
on
the few working on the PHP 8 magic.Yes to shared responsibility, no to failing to merge changes to 7.4 up
to master. Either we will want that change, in case it should be
merged immediately rather than kicking the can down the road, or it
does not belong on master and we should null-merge it like we would
any other bugfix today. We must not put ourselves in the position of
7.4 being ahead of master. Period.Another option, by the way, would be ditching 7.4 altogether and focusing
our efforts on 8.0 right away. It does mean people won't get typed
properties in 2019, but it will mean they'll likely get PHP 8 sooner.As tempting as that may be, I think this would be incredibly
irresponsible to PHP users. 7.4 is a necessity on the grounds of
having a deprecations release alone, nevermind the availability of new
features.TLDR;
I'm willing to embrace an early fork for 7.4, but we treat it like a
normal fork, not a special-psuedo-feature-branch. I also strongly
oppose dropping 7.4 as a release.-Sara
I'm not sure how we got to 7.4 becoming a feature branch. The options as I
see it are:
- Fork PHP-7.4, make master PHP 8 and merge all commits up to master.
Likely means that many commits that could target 7.4 will be going into
master, because we really can't be bothered.- Keep PHP 7.4 on master and feature branch PHP-8.0-Preview, without
merging every commit. Everything that's not PHP 8 specific continues to
land on master and targets PHP 7.4.Both are sensible options, it depends on whether we want to focus
development on PHP 8.0 (first option) or PHP 7.4 (second option) at this
point in time. My vote goes to 2) for now. We should have a place for PHP 8
changes now, but with the release still being at least two years away I
don't think it should become our primary development branch just yet.hi,
After all, and despite of the first proposal was mine, now I think, we
should start from the second option.
in the near future (by mid January) fork PHP-8 and start active
development there. Keep PHP-7.4 development in master, and don't require
committers to merge into PHP-8, but restrict PHP-7.4 for minor changes
or features that won't significantly affect PHP-8 branch.in May/June move master into PHP-7.4, make PHP-8 to be master and
require committers to work on master and backport changes (according to
usual PHP/GIT workflow).To target typed-properties or other significant changes to PHP-7.4, it's
better to commit them before PHP-8 branching.Thanks. Dmitry.
in the near future (by mid January) fork PHP-8 and start active
development there. Keep PHP-7.4 development in master, and don't require
committers to merge into PHP-8, but restrict PHP-7.4 for minor changes
or features that won't significantly affect PHP-8 branch.in May/June move master into PHP-7.4, make PHP-8 to be master and
require committers to work on master and backport changes (according to
usual PHP/GIT workflow).If fixes are not required to be merged to PHP-8, then how do we ensure
that those fixes (especially the security ones) will still be in
effect when 8.0 is released?
Changes are still merged into 8.0. It's just not the responsibility of the
individual contributor to merge every single commit as it is made. Instead
the people working on the PHP 8 branch perform merges as needed. E.g.
Dmitry has been maintaining a JIT branch for many years now, by
semi-regularly merging current master into it.
Basically just the way a standard long-term feature branch works.
To target typed-properties or other significant changes to PHP-7.4, it's
better to commit them before PHP-8 branching.
How will that impact deprecations? Are we calling those "not
significant"? I'd actually say yeah since they tend to take the form
of a few lines of "stop doing this". I do worry about our ability to
pull a deprecations list together by January though.
Deprecations have to go into 7.4, there's no other option there. Creating a
PHP 8 feature branch does not mean that changes (even language changes)
can't be applied to PHP 7.4. It may be slightly more convenient if large
changes like typed properties land before branching, but it's not a hard
requirement.
FTR; This feels like the worst available option. It's basically just
early branching with bad names. I'd much sooner branch PHP-7.4 in
January and have that be it.
I feel like there may be some understanding here, because what is proposed
here seems to match exactly what you proposed in your first mail to this
thread.
Nikita
I feel like there may be some understanding here, because what
is proposed here seems to match exactly what you proposed
in your first mail to this thread.
Perhaps the impedance mismatch is in calling the branch "PHP-8".
Calling it that says to me, "It's my responsibility to merge bugfixes
if I want them propagated to what will become 8.0.0-final". Calling
it "feature/jit-and-other-cool-stuff" or literally ANYTHING other than
"8" says, "Development is happening as normal, and the feature branch
is the problem of the people working on the feature.
Also, I'm going to quote again the specific language Dmitry used:
- in May/June move master into PHP-7.4, make PHP-8 to be master and
require committers to work on master and backport changes (according to
usual PHP/GIT workflow).
"move" says to me "rename the branches", which again, if fixes aren't
being dutifully picked/merged/whatever to this branch, then they
inevitably will get lost. It's not that I don't trust someone working
on the feature branch to do their best, it's that it shouldn't be
their responsibility.
-Sara
I feel like there may be some understanding here, because what
is proposed here seems to match exactly what you proposed
in your first mail to this thread.Perhaps the impedance mismatch is in calling the branch "PHP-8".
Calling it that says to me, "It's my responsibility to merge bugfixes
if I want them propagated to what will become 8.0.0-final". Calling
it "feature/jit-and-other-cool-stuff" or literally ANYTHING other than
"8" says, "Development is happening as normal, and the feature branch
is the problem of the people working on the feature.Also, I'm going to quote again the specific language Dmitry used:
- in May/June move master into PHP-7.4, make PHP-8 to be master and
require committers to work on master and backport changes (according to
usual PHP/GIT workflow)."move" says to me "rename the branches", which again, if fixes aren't
being dutifully picked/merged/whatever to this branch, then they
inevitably will get lost. It's not that I don't trust someone working
on the feature branch to do their best, it's that it shouldn't be
their responsibility.-Sara
I'd like to bring this up again. Typed properties has been merged, so we
currently don't have any major code changes pending. To clarify what
exactly I'm proposing:
- Create the PHP-7.4 branch now/soon, rather than in summer.
- master will be PHP 8.0.
- All changes are applied to the lowest applicable branch and then merged
up as usual, including to PHP-7.4 and master. - NEWS mentions for bug fixes are only added up to PHP-7.3. They are not
added on the PHP-7.4 branch, just like for master. (Excluding changes that
are only in 7.4/8.0, of course.) - All feature additions can generally still go to the PHP-7.4 branch,
there is no freeze. - Backwards incompatible changes and major internal API changes can go to
master (assuming they are accepted through the usual processes).
Nikita
I'd like to bring this up again. Typed properties has been merged, so we
currently don't have any major code changes pending. To clarify what
exactly I'm proposing:
- Create the PHP-7.4 branch now/soon, rather than in summer.
- master will be PHP 8.0.
- All changes are applied to the lowest applicable branch and then merged
up as usual, including to PHP-7.4 and master.- NEWS mentions for bug fixes are only added up to PHP-7.3. They are not
added on the PHP-7.4 branch, just like for master. (Excluding changes that
are only in 7.4/8.0, of course.)- All feature additions can generally still go to the PHP-7.4 branch,
there is no freeze.- Backwards incompatible changes and major internal API changes can go to
master (assuming they are accepted through the usual processes).I'm on board with this. My prior objection was that the third point in
your list (all changes merged to master as usual) didn't appear to be the
plan during the earlier discussion. If it's the plan now, then +1 from me.
I do want to clarify your comment about not being in feature freeze for
7.4. I take this to mean not just that new implementations can be landed,
but that new RFCs can be put forward, voted on, approved, and merged. That
comes with the understanding that large ones SHOULD target 8.0, but they
don't necessarily have to.
-Sara
I'd like to bring this up again. Typed properties has been merged, so we
currently don't have any major code changes pending. To clarify what
exactly I'm proposing:
- Create the PHP-7.4 branch now/soon, rather than in summer.
- master will be PHP 8.0.
- All changes are applied to the lowest applicable branch and then merged
up as usual, including to PHP-7.4 and master.- NEWS mentions for bug fixes are only added up to PHP-7.3. They are not
added on the PHP-7.4 branch, just like for master. (Excluding changes that
are only in 7.4/8.0, of course.)- All feature additions can generally still go to the PHP-7.4 branch,
there is no freeze.- Backwards incompatible changes and major internal API changes can go to
master (assuming they are accepted through the usual processes).
IMHO, a sensible compromise to allow starting real work on PHP 8 while
still keeping 7.4 open for feature additions.
If we do so, I wonder whether we should prepone the 7.4 RM selection. I
had planned to issue a call for volunteers in early March, but maybe it
would be good to have RMs available earlier to supervise the PHP-7.4 branch.
--
Christoph M. Becker
Am 24.01.2019 um 15:52 schrieb Nikita Popov:
- Create the PHP-7.4 branch now/soon, rather than in summer.
- master will be PHP 8.0.
- All changes are applied to the lowest applicable branch and then merged
up as usual, including to PHP-7.4 and master.- NEWS mentions for bug fixes are only added up to PHP-7.3. They are not
added on the PHP-7.4 branch, just like for master. (Excluding changes that
are only in 7.4/8.0, of course.)- All feature additions can generally still go to the PHP-7.4 branch,
there is no freeze.- Backwards incompatible changes and major internal API changes can go to
master (assuming they are accepted through the usual processes).
Makes sense to me.
I feel like there may be some understanding here, because what
is proposed here seems to match exactly what you proposed
in your first mail to this thread.Perhaps the impedance mismatch is in calling the branch "PHP-8".
Calling it that says to me, "It's my responsibility to merge bugfixes
if I want them propagated to what will become 8.0.0-final". Calling
it "feature/jit-and-other-cool-stuff" or literally ANYTHING other than
"8" says, "Development is happening as normal, and the feature branch
is the problem of the people working on the feature.Also, I'm going to quote again the specific language Dmitry used:
- in May/June move master into PHP-7.4, make PHP-8 to be master and
require committers to work on master and backport changes (according to
usual PHP/GIT workflow)."move" says to me "rename the branches", which again, if fixes aren't
being dutifully picked/merged/whatever to this branch, then they
inevitably will get lost. It's not that I don't trust someone working
on the feature branch to do their best, it's that it shouldn't be
their responsibility.-Sara
I'd like to bring this up again. Typed properties has been merged, so we
currently don't have any major code changes pending. To clarify what
exactly I'm proposing:
- Create the PHP-7.4 branch now/soon, rather than in summer.
- master will be PHP 8.0.
- All changes are applied to the lowest applicable branch and then merged
up as usual, including to PHP-7.4 and master.- NEWS mentions for bug fixes are only added up to PHP-7.3. They are not
added on the PHP-7.4 branch, just like for master. (Excluding changes that
are only in 7.4/8.0, of course.)- All feature additions can generally still go to the PHP-7.4 branch,
there is no freeze.- Backwards incompatible changes and major internal API changes can go to
master (assuming they are accepted through the usual processes).Nikita
As long as someone will help me get the covariance/contravariance
patch merged in correctly when the time comes, I'm all for it.
On Fri, Nov 16, 2018 at 9:26 AM Nikita Popov nikita.ppv@gmail.com
wrote:I feel like there may be some understanding here, because what
is proposed here seems to match exactly what you proposed
in your first mail to this thread.Perhaps the impedance mismatch is in calling the branch "PHP-8".
Calling it that says to me, "It's my responsibility to merge bugfixes
if I want them propagated to what will become 8.0.0-final". Calling
it "feature/jit-and-other-cool-stuff" or literally ANYTHING other than
"8" says, "Development is happening as normal, and the feature branch
is the problem of the people working on the feature.Also, I'm going to quote again the specific language Dmitry used:
- in May/June move master into PHP-7.4, make PHP-8 to be master and
require committers to work on master and backport changes (according
to
usual PHP/GIT workflow)."move" says to me "rename the branches", which again, if fixes aren't
being dutifully picked/merged/whatever to this branch, then they
inevitably will get lost. It's not that I don't trust someone working
on the feature branch to do their best, it's that it shouldn't be
their responsibility.-Sara
I'd like to bring this up again. Typed properties has been merged, so we
currently don't have any major code changes pending. To clarify what
exactly I'm proposing:
- Create the PHP-7.4 branch now/soon, rather than in summer.
- master will be PHP 8.0.
- All changes are applied to the lowest applicable branch and then
merged
up as usual, including to PHP-7.4 and master.- NEWS mentions for bug fixes are only added up to PHP-7.3. They are not
added on the PHP-7.4 branch, just like for master. (Excluding changes
that
are only in 7.4/8.0, of course.)- All feature additions can generally still go to the PHP-7.4 branch,
there is no freeze.- Backwards incompatible changes and major internal API changes can go
to
master (assuming they are accepted through the usual processes).Nikita
As long as someone will help me get the covariance/contravariance
patch merged in correctly when the time comes, I'm all for it.
As the reception seems positive, I'll go ahead and create the branch now.
Nikita