Hi,
Long due but finally sending the final RFC for the release process.
There a couple of changes since the last time, they are all about
making it more transparent or catch the edge cases. We also got new
proposers on board, we are now basically almost all active devs on
board.
URL: https://wiki.php.net/rfc/releaseprocess
In parallel to the current discussions about 5.4's features, let get
this RFC approved and use right away for 5.3 (to define its life time)
and 5.4. That will spare us the issues we had in the past with 5.3,
for example and ensure that we get 5.4 release in a reasonable
timeframe and without endless delays, or features additions.
It is important to keep in mind that this RFC is not written in stone
but it is a good base to begin with. We can always adapt it later, if
necessary.
https://wiki.php.net/rfc/releaseprocess/vote for the votes, pls add
your svn id. Proposers do not need to do it as they are indeed there
as +1 already (I added myself as example)
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Hi,
In my opinion a restriction "API compatibility must be kept (internals
and userland)" for x.y.z to x.y+1.z is too strict. It just can block
some new features forever.
I would suggest to change "API compatibility must be kept" to "API
backward compatibility must be kept as much as possible".
Thanks. Dmitry.
Hi,
Long due but finally sending the final RFC for the release process.
There a couple of changes since the last time, they are all about
making it more transparent or catch the edge cases. We also got new
proposers on board, we are now basically almost all active devs on
board.URL: https://wiki.php.net/rfc/releaseprocess
In parallel to the current discussions about 5.4's features, let get
this RFC approved and use right away for 5.3 (to define its life time)
and 5.4. That will spare us the issues we had in the past with 5.3,
for example and ensure that we get 5.4 release in a reasonable
timeframe and without endless delays, or features additions.It is important to keep in mind that this RFC is not written in stone
but it is a good base to begin with. We can always adapt it later, if
necessary.https://wiki.php.net/rfc/releaseprocess/vote for the votes, pls add
your svn id. Proposers do not need to do it as they are indeed there
as +1 already (I added myself as example)Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
hi,
Hi,
In my opinion a restriction "API compatibility must be kept (internals and
userland)" for x.y.z to x.y+1.z is too strict. It just can block some new
features forever.
btw, new APIs do not break API or API.
I do not think we should allow BC breaks between x.y and x.y+1. That's
counter productive and prevent users to migrate easily and quicker.
That's the whole point of having more frequent releases.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
hi,
Hi,
In my opinion a restriction "API compatibility must be kept (internals and
userland)" for x.y.z to x.y+1.z is too strict. It just can block some new
features forever.btw, new APIs do not break API or API.
I mean API or ABI.
I do not think we should allow BC breaks between x.y and x.y+1. That's
counter productive and prevent users to migrate easily and quicker.
That's the whole point of having more frequent releases.
We could allow BC break internally, using your wording, but that's
something I do not like either.
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
That isn't measurable, so it is a suggestion, not a standard. It also creates serious problems in userland if APIs change. API changes lead hosts to literally take years to update to new versions of PHP, for fear of breaking the sites that host with them. What about:
Userland API compatibility of documented interfaces and behaviors must be kept. API internals should be backwards compatible wherever possible.
This relaxes the userland restriction just slightly to allow for changes that break undocumented behaviors, but leaves it basically stable and measurable. This also leaves the door open for internal changes if they're really needed, but basically suggests against it.
John Crenshaw
Priacta, Inc.
-----Original Message-----
From: Dmitry Stogov [mailto:dmitry@zend.com]
Sent: Wednesday, June 01, 2011 7:08 AM
To: Pierre Joye
Cc: PHP internals
Subject: Re: [PHP-DEV] Final version, RFC release process
Hi,
In my opinion a restriction "API compatibility must be kept (internals
and userland)" for x.y.z to x.y+1.z is too strict. It just can block
some new features forever.
I would suggest to change "API compatibility must be kept" to "API
backward compatibility must be kept as much as possible".
Thanks. Dmitry.
Before now each major (5.y+1) release introduced API changes.
We just couldn't introduce literal tables, interned strings, etc without
API changes.
However such API breaks where invisible for user-land and most
extensions, they required a lot of changes in O+, APC, xdebug, etc.
But, in case we freeze the API we just won't be able to add many future
improvements.
Thanks. Dmitry.
That isn't measurable, so it is a suggestion, not a standard. It also creates serious problems in userland if APIs change. API changes lead hosts to literally take years to update to new versions of PHP, for fear of breaking the sites that host with them. What about:
Userland API compatibility of documented interfaces and behaviors must be kept. API internals should be backwards compatible wherever possible.
This relaxes the userland restriction just slightly to allow for changes that break undocumented behaviors, but leaves it basically stable and measurable. This also leaves the door open for internal changes if they're really needed, but basically suggests against it.
John Crenshaw
Priacta, Inc.-----Original Message-----
From: Dmitry Stogov [mailto:dmitry@zend.com]
Sent: Wednesday, June 01, 2011 7:08 AM
To: Pierre Joye
Cc: PHP internals
Subject: Re: [PHP-DEV] Final version, RFC release processHi,
In my opinion a restriction "API compatibility must be kept (internals
and userland)" for x.y.z to x.y+1.z is too strict. It just can block
some new features forever.I would suggest to change "API compatibility must be kept" to "API
backward compatibility must be kept as much as possible".Thanks. Dmitry.
Hi!
Before now each major (5.y+1) release introduced API changes.
We just couldn't introduce literal tables, interned strings, etc without
API changes.
I think by API there it means PHP-level API, i.e. one exposed to the
user, not binary API exposed to the extensions, which is meant by ABI.
So what should be preserved is PHP function signatures, classes, syntax,
INI settings, etc. but internals can change.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
There's something between the user level API and the ABI - which is source level compatibility.
What Dmitry's pointing out that if we commit to source level compatibility, it'll be quite limiting (based on past experience). If we don't commit to source-level compatibility then we're fine. I guess we can say we'll strive for source level compatibility, but not have it as a 'must'.
Zeev
-----Original Message-----
From: Stas Malyshev [mailto:smalyshev@sugarcrm.com]
Sent: Wednesday, June 01, 2011 7:51 PM
To: Dmitry Stogov
Cc: John Crenshaw; PHP internals
Subject: Re: [PHP-DEV] Final version, RFC release processHi!
Before now each major (5.y+1) release introduced API changes.
We just couldn't introduce literal tables, interned strings, etc
without API changes.I think by API there it means PHP-level API, i.e. one exposed to the user, not
binary API exposed to the extensions, which is meant by ABI.
So what should be preserved is PHP function signatures, classes, syntax, INI
settings, etc. but internals can change.--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227--
To unsubscribe, visit:
http://www.php.net/unsub.php
Hi!
There's something between the user level API and the ABI - which is source level compatibility.
That's a good point. We'd like to keep source-level incompatibilities to
a minimum - especially for simple extensions, not like APC :) - but I
agree it may be hard to maintain at 100% if we do engine improvements.
Maybe we should have different criteria for something like APC (which is
very deep in the internals) and something like memcached (which needs
much less from internals).
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Before now each major (5.y+1) release introduced API changes.
We just couldn't introduce literal tables, interned strings, etc without API
changes.However such API breaks where invisible for user-land and most extensions,
they required a lot of changes in O+, APC, xdebug, etc.But, in case we freeze the API we just won't be able to add many future
improvements.
Userland BC must be kept between x.y and x.y+1, that's the primary
goal of this section. PHP userland is only about API compatibility and
how PHP behaves.
However, what you refer to is about internals API. We can (and did a
lot) break ABI between x.y and x.y+1 and should really avoid breaking
API (read: signatures, source compatibility) if possible.
To make it more clear, here are some good explanations about API and ABI:
http://stackoverflow.com/questions/3784389/difference-between-api-and-abi
http://en.wikipedia.org/wiki/Application_binary_interface
http://en.wikipedia.org/wiki/Application_programming_interface
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
However, what you refer to is about internals API. We can (and did a
lot) break ABI between x.y and x.y+1 and should really avoid breaking API
(read: signatures, source compatibility) if possible.
I think we need to clear it up in the RFC. My take:
- Switch from talking about 'ABI' to 'extension API'
- Divide the extension API into source-level and binary-level
- For x.y+1, make it clear that there's no need to retain binary-level extension API, and that source-level extension API is a 'should' and not a 'must'.
Zeev
However, what you refer to is about internals API. We can (and did a
lot) break ABI between x.y and x.y+1 and should really avoid breaking API
(read: signatures, source compatibility) if possible.I think we need to clear it up in the RFC. My take:
- Switch from talking about 'ABI' to 'extension API'
- Divide the extension API into source-level and binary-level
- For x.y+1, make it clear that there's no need to retain binary-level extension API, and that source-level extension API is a 'should' and not a 'must'.
On it, adding the reference to ABI/API definition as well.
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Comments again-they are mostly similar as before-I was quite annoyed
that I didn't even get feedback on when I sent it last time:
==== Example time line with two majors versions ====
However it could happen that a new major version is desired while the
active major version is still heavily used. Like what we had between
php 4 and 5 or for the oldest, between php 3 and 4.
Because of this, Perhaps the latest release before a new major one
should run for a year longer. So in the example above, 5.6 runs until
where 6.0 ends too.
<code> **** pre release phase ++++ release lifetime bugs ---- release lifetime security only D EOL Version Time -> 2011 2012 2013 2014 2015 2016 2017 | | | | | | | | | | | | | 5.3 +++++++++++++-----D 5.4 |*****+++++++++++++++++++++++++-----------D | | | | | 5.5 | | |******++++++++++++++++++++++++-----------D | | | 5.6 | | | |******++++++++++++++++++++++++-----------D 6.0 | | |******++++++++++++++++++++++++-----------D | | 6.1 | | | |******++++++++++++++++++++++++-----------D </code>
This variant is not workable, because there are (in the example) in 2014
five branches. Merging between those, manually and automatically is
going to be a major pain. I'd say we all rather want to focus our time
on fixes and new features; and not spend more time doing branch merging,
whatever tool we use for this.
I prefer the other one that was suggested before:
==== Example time line with only one major version at a time ====
<code>
**** pre release phase
++++ release lifetime with all bugs fixes, no feature addition
---- release lifetime security fixes only
D EOL
Version Time ->
2011 2012 2013 2014 2015 2016 2017
| | | | | | | | | | | | |
5.3 +++++++++++++-----D
5.4 |+++++++++++++++++++++++++-----------D
5.5 | | |++++++++++++++++++++++++-----------D
5.6 | | | | |++++++++++++++++++++++++-----------D
6.0 | | | | |++++++++++++++++++++++++-----------D
6.1 | | | | |*****++++++++++++++++++++++++-----------D
</code>
==== Timeline example for a release ====
- June
- Decisions which features or changes will be in the next release
- 1st release alpha (may have many alpha)
- At least one release per month, more at wish
- Septempber, RC phases, biweekly release
- each RC should go through the QA before being published
- usually2 days
Uh? The whole RC phase is QA. I don't see why you need another QA
'period'.
I would however want to say that packaging and bundling is
done on Wednesday, with any release on Thursday (morning). The original
idea was to not have just a Friday for people to upgrade before a
weekend. I've always bundled/packages on Wednesday and released on
Thursday, but I've seen that lately it's all done on Thursday, and
sometimes even Thursday evening US time.
* running the various test suites (phpt, custom real life tests, platform specific tests). Some tests need a day to run
- November, Final
- Last RC taken as final, golden release (no change between the last RC and the final version)
TBH, I think 6 months is too much between first alpha and release.
Because we'd only have 6 months for a "normal cycle".
===== Feature selection and development =====
RFCs have been introduced two years ago and have been proven as being
an amazing way to avoid conflicts while providing a very good way to
propose new things to php.net. New features or additions to the core
should go through the RFC process.
New big language features, I agree with. Small little self-contained
extension functions do not need a full blown RFC process. Extension's
maintainers should have the responsibilty for this. (I am not saying it
wouldn't be good to have an RFC for some of those new additions though).
It has been done successfully (as
the process went well, but the features were not necessary accepted)
already for a dozen of new features or improvements.
One issue with it though, the page that lists all the RFCs isn't
maintained, and status isn't always updated. That needs to be done
otherwise we get to "oh, is this implemented yet?"
Features can use branch(es) if necessary, doing so will minimize the
impact of other commits and changes on the development of a specific
feature (or the other way 'round). The shorter release cycle also
ensures that a given feature can get into the next release, as long as
the RFC has been accepted.
I would word "can use branches if necessary" stronger, like "can use
branches if absolutely necessary". The reason why, is that it is a good
idea to get as many people familiar with new code. Of course, if there
is a lot of ongoing work then a feature branch helps, but it should be
merged into trunk as soon as it compiles (and doesn't break any test
case) for peer review and more testing.
The change to what we have now is the voting process. It will not
happen anymore on the mailing list but in the RFCs directly, for
php.net members, in an anonymous way (who votes what won't be made
public).The question for this section is about who will be allowed to vote:
- php-src (yes, no)
- php-doc (yes, no)
- qa, *phpt (yes, no)
- other sub projects like pear (yes, no)
NB: the poll plugin will be installed shortly
A few things here that I don't like. First of all, I think voting
should be public. I've nothing to hide, and I hope nobody else has
either. Voting just on a wiki is too hidden as well- I think it should
happen on the mailinglist with just +1, 0 and -1 responses. I quite like
the Apache model: http://www.apache.org/foundation/voting.html and
wouldn't mind adopting that in a slightly modified way. It is important
however that votes come without comments.
===== Feature(s) preview release, solving the experimental features =====
Some features require a lot of testing or users feedback before they
can be considered as ready, stable enough or proven as having made
good design decisions. Having them in normal releases is dangerous.
The past releases told us more that once than many good ideas ended as
being not so good after all. But we had to keep them in and, even
worst, maintain them forever.A feature preview release could solve this problem. A feature(s)
preview release gives us and our users a way to try bleeding edge
additions to the language or core while providing us with an
invaluable feedback to actually valid both the implementation and the
design choices.
Non core features (engine, stream, etc.) could benefit from a feature
preview release while doing it via PECL should be the preferred way.Feature(s) preview releases can happen any time and can be platform
specific. Whether a specific development branch is used or not is up
to the developers of the given features (external repositories like
github or bitbucket can obviously be used as well).
Isn't a feature preview just a snapshot or (the first) alpha? I don't
want to see various feature releases that don't have just trunk. The
reason being mostly is that we would want to avoid splintering of
"what is PHP"? Even more, because if we say "feature release" people
might actually start using that to write applications against. I also
don't see with being platform specific has to do with this. PHP is PHP,
and on each platform PHP is (or at least should be) behaving the same.
That also brings me to the point that all our downloads should be in one
place: http://snaps.php.net for snapshots, and
http://php.net/releases/index.php for releases. It makes no sense to
have them spread over multiple locations.
cheers,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
This variant is not workable, because there are (in the example) in 2014
five branches. Merging between those, manually and automatically is
going to be a major pain. I'd say we all rather want to focus our time
on fixes and new features; and not spend more time doing branch merging,
whatever tool we use for this.
This is similar to my initial point about the proposal. We need to
figure out a way to have fewer active bug-fix branches, just because
it make dev live very difficult. Derick I am not sure your example is
much better, since you still have 4 active branches (if I am reading
the diagram correctly). I think 3 active bug fix branches, with maybe
1 security fixes only branches is the most we should have.
This variant is not workable, because there are (in the example) in 2014
five branches. Merging between those, manually and automatically is
going to be a major pain. I'd say we all rather want to focus our time
on fixes and new features; and not spend more time doing branch merging,
whatever tool we use for this.This is similar to my initial point about the proposal. We need to
figure out a way to have fewer active bug-fix branches, just because
it make dev live very difficult. Derick I am not sure your example is
much better, since you still have 4 active branches (if I am reading
the diagram correctly). I think 3 active bug fix branches, with maybe
1 security fixes only branches is the most we should have.
yes, and we can adapt that in time and when necessary.
The core of this RFC however is still valid and is a very good step
forward for our project (that's for Derick's reply).
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
This variant is not workable, because there are (in the example) in 2014
five branches. Merging between those, manually and automatically is
going to be a major pain. I'd say we all rather want to focus our time
on fixes and new features; and not spend more time doing branch merging,
whatever tool we use for this.This is similar to my initial point about the proposal. We need to
figure out a way to have fewer active bug-fix branches, just because
it make dev live very difficult. Derick I am not sure your example is
much better, since you still have 4 active branches (if I am reading
the diagram correctly). I think 3 active bug fix branches, with maybe
1 security fixes only branches is the most we should have.
I mentioned this before: I like the Ubuntu model:
- One development branch for the next version
- One current version
- One "long term" supported version
The current version is aimed to give early access to new features, to
avoid cases like traits which take years to come out while a bit more
conservative users (and maybe distros) may stay on the LTS. Once a new
"current" comes out there won't be fixes for the previous anymore.
Every n-th "current" release will be a long term supported (LTS) release
receiving only only only bug fixing and the older it gets the more
critical bugs, only. What "long term" means can be discussed.
It is open for discussion if a LTS version will directly terminate the
previous LTS version or whether an LTS version will be released instead
of an "current" version, so for one period there would be two LTS but no
"current" branch.
johannes
Sounds reasonable.
2011/6/1 Johannes Schlüter johannes@schlueters.de:
This variant is not workable, because there are (in the example) in 2014
five branches. Merging between those, manually and automatically is
going to be a major pain. I'd say we all rather want to focus our time
on fixes and new features; and not spend more time doing branch merging,
whatever tool we use for this.This is similar to my initial point about the proposal. We need to
figure out a way to have fewer active bug-fix branches, just because
it make dev live very difficult. Derick I am not sure your example is
much better, since you still have 4 active branches (if I am reading
the diagram correctly). I think 3 active bug fix branches, with maybe
1 security fixes only branches is the most we should have.I mentioned this before: I like the Ubuntu model:
- One development branch for the next version
- One current version
- One "long term" supported version
The current version is aimed to give early access to new features, to
avoid cases like traits which take years to come out while a bit more
conservative users (and maybe distros) may stay on the LTS. Once a new
"current" comes out there won't be fixes for the previous anymore.
Every n-th "current" release will be a long term supported (LTS) release
receiving only only only bug fixing and the older it gets the more
critical bugs, only. What "long term" means can be discussed.
It is open for discussion if a LTS version will directly terminate the
previous LTS version or whether an LTS version will be released instead
of an "current" version, so for one period there would be two LTS but no
"current" branch.johannes
hi,
2011/6/1 Johannes Schlüter johannes@schlueters.de:
This variant is not workable, because there are (in the example) in 2014
five branches. Merging between those, manually and automatically is
going to be a major pain. I'd say we all rather want to focus our time
on fixes and new features; and not spend more time doing branch merging,
whatever tool we use for this.This is similar to my initial point about the proposal. We need to
figure out a way to have fewer active bug-fix branches, just because
it make dev live very difficult. Derick I am not sure your example is
much better, since you still have 4 active branches (if I am reading
the diagram correctly). I think 3 active bug fix branches, with maybe
1 security fixes only branches is the most we should have.I mentioned this before: I like the Ubuntu model:
- One development branch for the next version
- One current version
- One "long term" supported version
I do not like it. It does not apply to a programming language and its
requirement from an end user point of view.
To have a fixed life span for each x.y (5.3, 5.4, 6.0, etc.) is a
drastic improvement for ISPs, framework developers etc.
The issue about having multiple or too many branches active is a non
problem imo. Yes, it takes a couple of hours yet to release php, but
that's something that could be automated easily (the tasks, not the
whole thing) . It will also be much safer to do it given that no fancy
commits can or should be applied in patch releases/stable branches.
In addition we are getting more and more automated testing and that
will make the release processes even smoother and safer. Unlike now
where we need months to do 5.3 patches when we should have at least .7
already and .8 being in the work.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Pierre,
Doing a release could be simplified through automation as you've said.
However keeping synchronized patches across frequently incompatible
(non-identical) code bases is much less trivial and requires quite a
bit of work by anyone making the bug fixes. Having >3 branches for bug
fixes makes this very non-trivial and time consuming, which is why
Johannes' proposal is so appealing.
2011/6/1 Pierre Joye pierre.php@gmail.com:
hi,
2011/6/1 Johannes Schlüter johannes@schlueters.de:
This variant is not workable, because there are (in the example) in 2014
five branches. Merging between those, manually and automatically is
going to be a major pain. I'd say we all rather want to focus our time
on fixes and new features; and not spend more time doing branch merging,
whatever tool we use for this.This is similar to my initial point about the proposal. We need to
figure out a way to have fewer active bug-fix branches, just because
it make dev live very difficult. Derick I am not sure your example is
much better, since you still have 4 active branches (if I am reading
the diagram correctly). I think 3 active bug fix branches, with maybe
1 security fixes only branches is the most we should have.I mentioned this before: I like the Ubuntu model:
- One development branch for the next version
- One current version
- One "long term" supported version
I do not like it. It does not apply to a programming language and its
requirement from an end user point of view.To have a fixed life span for each x.y (5.3, 5.4, 6.0, etc.) is a
drastic improvement for ISPs, framework developers etc.The issue about having multiple or too many branches active is a non
problem imo. Yes, it takes a couple of hours yet to release php, but
that's something that could be automated easily (the tasks, not the
whole thing) . It will also be much safer to do it given that no fancy
commits can or should be applied in patch releases/stable branches.In addition we are getting more and more automated testing and that
will make the release processes even smoother and safer. Unlike now
where we need months to do 5.3 patches when we should have at least .7
already and .8 being in the work.Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
2011/6/1 Ilia Alshanetsky ilia@prohost.org:
Pierre,
Doing a release could be simplified through automation as you've said.
However keeping synchronized patches across frequently incompatible
(non-identical) code bases is much less trivial and requires quite a
bit of work by anyone making the bug fixes. Having >3 branches for bug
fixes makes this very non-trivial and time consuming, which is why
Johannes' proposal is so appealing.
I don't think we will ever have >3 releases for bug fixes but maybe
3-4 max with 2-3 in security modes. In this case it is really easy to
maintain and release.
Random LTS at random point with random life time for releases is not
something I want for PHP. It is basically what we have now and PHP
users are really not happy about that (and many devs).
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Am 01.06.2011 14:44, schrieb Johannes Schlüter:
I mentioned this before: I like the Ubuntu model:
- One development branch for the next version
- One current version
- One "long term" supported version
+1
The current version is aimed to give early access to new features, to
avoid cases like traits which take years to come out while a bit more
conservative users (and maybe distros) may stay on the LTS.
Traits is a really good example here, indeed.
--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/
The current version is aimed to give early access to new features, to
avoid cases like traits which take years to come out while a bit more
conservative users (and maybe distros) may stay on the LTS.Traits is a really good example here, indeed.
Please tell me how it differs to what we propose? aka yearly release
with fixed lifetime for each release? It is exactly about that, do not
have unreasonable delay between a feature readiness and its
availability in a release. While solving the plan-ability to migrate
to a give version, or allow migrations to newer versions without risk.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Am 01.06.2011 14:44, schrieb Johannes Schlüter:
I mentioned this before: I like the Ubuntu model:
- One development branch for the next version
- One current version
- One "long term" supported version
+1
+1
Regards,
Philip
* running the various test suites (phpt, custom real life tests,
platform specific tests). Some tests need a day to run
* November, Final
* Last RC taken as final, golden release (no change between the last RC and the final version)TBH, I think 6 months is too much between first alpha and release.
Because we'd only have 6 months for a "normal cycle".
That's a max and reasonable time frame based on what we had in the
past and based on discussions with the devs actually doing the work.
So what if we make it before? a wonder! But at least there is a max
deadline.
One issue with it though, the page that lists all the RFCs isn't
maintained, and status isn't always updated. That needs to be done
otherwise we get to "oh, is this implemented yet?"
help welcomes.
Features can use branch(es) if necessary, doing so will minimize the
impact of other commits and changes on the development of a specific
feature (or the other way 'round). The shorter release cycle also
ensures that a given feature can get into the next release, as long as
the RFC has been accepted.I would word "can use branches if necessary" stronger, like "can use
branches if absolutely necessary". The reason why, is that it is a good
idea to get as many people familiar with new code. Of course, if there
is a lot of ongoing work then a feature branch helps, but it should be
merged into trunk as soon as it compiles (and doesn't break any test
case) for peer review and more testing.
do not see a reason to change this part, it is self explaining and if
a developer likes to use an extra branche, then it is up to him as he
maintains that code anyway, at least for the development period.
The change to what we have now is the voting process. It will not
happen anymore on the mailing list but in the RFCs directly, for
php.net members, in an anonymous way (who votes what won't be made
public).The question for this section is about who will be allowed to vote:
* php-src (yes, no)
* php-doc (yes, no)
* qa, *phpt (yes, no)
* other sub projects like pear (yes, no)NB: the poll plugin will be installed shortly
A few things here that I don't like. First of all, I think voting
should be public.
Please read the RFC.
===== Feature(s) preview release, solving the experimental features =====
Isn't a feature preview just a snapshot or (the first) alpha?
no, and it may not be ready in time for a given release. And that
allows us to show something at any time to get more feedbacks from
users about a given complex or big feature/change without taking the
risk to break a given normal release. That sounds like a good solution
and can be done at any time.
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Hi,
From a userland perspective, there should be absolutely no feature addition in a "bugfix" version (x.y.Z+1) : we would see (just like what we see today) frameworks, apps, or libraries depending on specific bugfix releases, and this would not make php versioning easier to understand for anybody.
And for you core devs, this is an open window for bypassing the standard versioning process, which could result in long discussions or determining if a feature is a self-containing one or not, and should be released in a bugfix version.
Allowing these exceptions would not IMO enhance the release process...
Cheers
Benjamin Dubois
Le mercredi 1 juin 2011 à 12:09, Pierre Joye a écrit :
Hi,
Long due but finally sending the final RFC for the release process.
There a couple of changes since the last time, they are all about
making it more transparent or catch the edge cases. We also got new
proposers on board, we are now basically almost all active devs on
board.URL: https://wiki.php.net/rfc/releaseprocess
In parallel to the current discussions about 5.4's features, let get
this RFC approved and use right away for 5.3 (to define its life time)
and 5.4. That will spare us the issues we had in the past with 5.3,
for example and ensure that we get 5.4 release in a reasonable
timeframe and without endless delays, or features additions.It is important to keep in mind that this RFC is not written in stone
but it is a good base to begin with. We can always adapt it later, if
necessary.https://wiki.php.net/rfc/releaseprocess/vote for the votes, pls add
your svn id. Proposers do not need to do it as they are indeed there
as +1 already (I added myself as example)Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Pierre,
There are some immediately practical things here. Some things will
be a large jolt for the community and might be better introduced in
future releases.
Chris
Good:
- Scheduled releases
- Use of RFCs
- No PHP script breakages in x.y.z+1 releases
Too complex or not good:
- Number of concurrent branches: Johannes's suggestion was good
- Secret voting & automated polls: many things are not binary
decisions and need discussion - Feature preview release: good in theory. Is there any need to
formalize this since anyone can create a patch (or fork etc)?
Define & clarify for the lay reader:
- "External API", "Internal API", ABI, "internals", "userland"
--
Email: christopher.jones@oracle.com
Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/
hi Chris
On Thu, Jun 2, 2011 at 12:34 AM, Christopher Jones
christopher.jones@oracle.com wrote:
Pierre,
There are some immediately practical things here. Some things will
be a large jolt for the community and might be better introduced in
future releases.Chris
Good:
- Scheduled releases
- Use of RFCs
- No PHP script breakages in x.y.z+1 releasesToo complex or not good:
- Number of concurrent branches: Johannes's suggestion was good
This proposal for distros not for programming languages or similar
tools. All users I talk to need fixed timeline, life cycle, etc. to
have a clear and plan-able way to deal with php versions.
- Secret voting & automated polls: many things are not binary
decisions and need discussion
There is no secret voting.
- Feature preview release: good in theory. Is there any need to
formalize this since anyone can create a patch (or fork etc)?
Yes, just to explain what it is and tell devs they can do it and (<
that's important) publish it.
Define & clarify for the lay reader:
- "External API", "Internal API", ABI, "internals", "userland"
On it :)
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
hi Chris
On Thu, Jun 2, 2011 at 12:34 AM, Christopher Jones
christopher.jones@oracle.com wrote:Pierre,
There are some immediately practical things here. Some things will
be a large jolt for the community and might be better introduced in
future releases.Chris
Good:
- Scheduled releases
- Use of RFCs
- No PHP script breakages in x.y.z+1 releases
Too complex or not good:
- Number of concurrent branches: Johannes's suggestion was good
This proposal for distros not for programming languages or similar
tools. All users I talk to need fixed timeline, life cycle, etc. to
have a clear and plan-able way to deal with php versions.
Sorry for jumping into the thread, but I couldn't help noting that you seem
confused about the distro suggestion. I think Ubuntu was the example, and
there's nothing random at all about their release process. There are fixed
timelines and life cycles in Ubuntu - having less branches does not in any
way stop them from having a fixed release process and schedule.
Regards
Peter
Sorry for jumping into the thread, but I couldn't help noting that you seem
confused about the distro suggestion. I think Ubuntu was the example, and
there's nothing random at all about their release process. There are fixed
timelines and life cycles in Ubuntu - having less branches does not in any
way stop them from having a fixed release process and schedule.
It is about "random" release being chosen as LTS. For many users, it
will preventing migration until a given feature is part of a LTS
release.
Our proposal to have fixed life time and release cycles does not have
this random effect and each x.y release is equally supported for the
same duration. The amount of branches can be reduced easily and even
if we may have many at one point, it will be only about sec fixes,
that's really not a problem (a bit of automated tasked will help here
too).
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Sorry for jumping into the thread, but I couldn't help noting that you seem
confused about the distro suggestion. I think Ubuntu was the example, and
there's nothing random at all about their release process. There are fixed
timelines and life cycles in Ubuntu - having less branches does not in any
way stop them from having a fixed release process and schedule.
It is about "random" release being chosen as LTS. For many users, it
will preventing migration until a given feature is part of a LTS
release.Our proposal to have fixed life time and release cycles does not have
this random effect and each x.y release is equally supported for the
same duration. The amount of branches can be reduced easily and even
if we may have many at one point, it will be only about sec fixes,
that's really not a problem (a bit of automated tasked will help here
too).Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Johannes said:
Every n-th "current" release will be a long term supported (LTS) release
That doesn't sound very random to me if n is constant.
That said, I'm not sure if an LTS is a good idea. One of the biggest
frustrations for me as a developer is hosts taking forever to upgrade to
newer versions of PHP. Most hosts I've seen are still on 5.2, and some
don't seem to have plans of upgrading to 5.3 any time soon. To me, an
LTS release would just make this situation worse, although the upside is
that at least we'd still be getting security fixes.
If however the LTS release lifetime is similar to the current y release
(x.y.z) then maybe it won't be so bad as it would grant earlier and
stable access to new features for those who have control over their php
installs, while retain a more long term supported release that hosts
would be happy with.
Cheers,
David
Am 02.06.2011 11:36, schrieb David Muir:
That said, I'm not sure if an LTS is a good idea. One of the biggest
frustrations for me as a developer is hosts taking forever to upgrade to
newer versions of PHP. Most hosts I've seen are still on 5.2, and some
don't seem to have plans of upgrading to 5.3 any time soon. To me, an
LTS release would just make this situation worse, although the upside is
that at least we'd still be getting security fixes.If however the LTS release lifetime is similar to the current y release
(x.y.z) then maybe it won't be so bad as it would grant earlier and
stable access to new features for those who have control over their php
installs, while retain a more long term supported release that hosts
would be happy with
you will always have idiots thinking "old is stable" and it is your
choice to do not support customers with such setups and you
have to define minimum requirements for projects
this has nothing to do with LTS or not LTS
as example: we require php5.3 and if somebody has a unusable hoster
the domain is transferred to our infrastructure and all problems
gone away
Sorry for jumping into the thread, but I couldn't help noting that you seem
confused about the distro suggestion. I think Ubuntu was the example, and
there's nothing random at all about their release process. There are fixed
timelines and life cycles in Ubuntu - having less branches does not in any
way stop them from having a fixed release process and schedule.It is about "random" release being chosen as LTS. For many users, it
will preventing migration until a given feature is part of a LTS
release.Our proposal to have fixed life time and release cycles does not have
this random effect and each x.y release is equally supported for the
same duration. The amount of branches can be reduced easily and even
if we may have many at one point, it will be only about sec fixes,
that's really not a problem (a bit of automated tasked will help here
too).
Then it's an argument about wording, not content. See
https://wiki.ubuntu.com/Releases : the LTS have fixed life time and
come at fixed intervals - basically exactly the same you propose with
"fixed life time and release cycles".
Regards
Peter
--
<hype>
WWW: plphp.dk / plind.dk
LinkedIn: plind
BeWelcome/Couchsurfing: Fake51
Twitter: kafe15
</hype
Sorry for jumping into the thread, but I couldn't help noting that you seem
confused about the distro suggestion. I think Ubuntu was the example, and
there's nothing random at all about their release process. There are fixed
timelines and life cycles in Ubuntu - having less branches does not in any
way stop them from having a fixed release process and schedule.It is about "random" release being chosen as LTS. For many users, it
will preventing migration until a given feature is part of a LTS
release.Our proposal to have fixed life time and release cycles does not have
this random effect and each x.y release is equally supported for the
same duration. The amount of branches can be reduced easily and even
if we may have many at one point, it will be only about sec fixes,
that's really not a problem (a bit of automated tasked will help here
too).Then it's an argument about wording, not content. See
https://wiki.ubuntu.com/Releases : the LTS have fixed life time and
come at fixed intervals - basically exactly the same you propose with
"fixed life time and release cycles".
No, it is the same that what we proposed. What we proposed is that
every release is actually a LTS release. What Ubuntu uses works fine
for distros given that it is a distro with an insane amount of totally
unrelated projects they distribute, and alternative repositories exist
for almost each of them.
For a programming language, it is a totally different story.
for ref: https://wiki.ubuntu.com/LTS
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
snip
No, it is the same that what we proposed. What we proposed is that
every release is actually a LTS release. What Ubuntu uses works fine
for distros given that it is a distro with an insane amount of totally
unrelated projects they distribute, and alternative repositories exist
for almost each of them.For a programming language, it is a totally different story.
That makes more sense - you were, however, arguing against random LTS
releases which was rather confusing (there's a big difference between
"every release is an LTS" and "all LTS releases are random" - those
are not the only options).
Regards
Peter
--
<hype>
WWW: plphp.dk / plind.dk
LinkedIn: plind
BeWelcome/Couchsurfing: Fake51
Twitter: kafe15
</hype
snip
No, it is the same that what we proposed. What we proposed is that
every release is actually a LTS release. What Ubuntu uses works fine
for distros given that it is a distro with an insane amount of totally
unrelated projects they distribute, and alternative repositories exist
for almost each of them.For a programming language, it is a totally different story.
That makes more sense - you were, however, arguing against random LTS
releases which was rather confusing (there's a big difference between
"every release is an LTS" and "all LTS releases are random" - those
are not the only options).
The randomness is about which release-features tuples would become a
LTS, that's something that can't apply well to a project like php.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
snip
No, it is the same that what we proposed. What we proposed is that
every release is actually a LTS release. What Ubuntu uses works fine
for distros given that it is a distro with an insane amount of totally
unrelated projects they distribute, and alternative repositories exist
for almost each of them.For a programming language, it is a totally different story.
That makes more sense - you were, however, arguing against random LTS
releases which was rather confusing (there's a big difference between
"every release is an LTS" and "all LTS releases are random" - those
are not the only options).The randomness is about which release-features tuples would become a
LTS, that's something that can't apply well to a project like php.
It's hard to see how that would be any more or less random than now,
given that it would still be a question of votes or consensus.
Presumably, features would not be removed (unless they were bad for
the language) and so they would still make it into LTS releases - the
next one up.
Anyway, I'll stop it here, as I doubt I'll convince you of anything
(and vice versa).
Just one thing to add: thanks for the work on PHP :) Much appreciated.
Regards
Peter
--
<hype>
WWW: plphp.dk / plind.dk
LinkedIn: plind
BeWelcome/Couchsurfing: Fake51
Twitter: kafe15
</hype
snip
No, it is the same that what we proposed. What we proposed is that
every release is actually a LTS release. What Ubuntu uses works fine
for distros given that it is a distro with an insane amount of totally
unrelated projects they distribute, and alternative repositories exist
for almost each of them.For a programming language, it is a totally different story.
That makes more sense - you were, however, arguing against random LTS
releases which was rather confusing (there's a big difference between
"every release is an LTS" and "all LTS releases are random" - those
are not the only options).The randomness is about which release-features tuples would become a
LTS, that's something that can't apply well to a project like php.It's hard to see how that would be any more or less random than now,
given that it would still be a question of votes or consensus.
I was referring to accepted features. Once they are accepted (and
implemented), our proposal makes sure that they will be in the next
release, which will happen within a year. And this next release will
have the same lifetime than any other.
Presumably, features would not be removed (unless they were bad for
the language) and so they would still make it into LTS releases - the
next one up.
That's a different topic and it is covered by the BC breakages policy.
Only major versions bump allows that.
Anyway, I'll stop it here, as I doubt I'll convince you of anything
(and vice versa).
Heh, that's why we discuss, exchange views and oppinions :)
Just one thing to add: thanks for the work on PHP :) Much appreciated.
You are welcome :)
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Am 02.06.2011 13:15, schrieb Peter Lind:
Anyway, I'll stop it here, as I doubt I'll convince you of anything
(and vice versa).Just one thing to add: thanks for the work on PHP :) Much appreciated.
I think/hope that this RFC is a step in the right direction to make the
release process clearer and more transparent for every interested
userland developer. So from me a big "THANK YOU" to all involved.
Christian