[RFC] Release Process View as Markdown

Hi,

With the recent chaos in the way we begin and ended releases, we would
like to propose a clean way to deal with releases and related decisions: [1]

Thanks for preparing this. I have one change proposal:

With the proposed model it might, as you have illustrated, happen that
there are 5 versions being maintained.

As I mentioned multiple times on this list, on irc and other places I
like a Ubuntu-like model with two kinds of release which I, for the
purpose of this discussion, call "early access" (EA) and "long term
supported" (LTS) version.

At any given time only one EA may exist. When a new LTS version is being
released the previous LTS version enters security-only mode to give
users a transition period. Between every LTS version there are two EA
versions.

   2011        2012       2013         2014        2015        2016        2017
    |     |     |     |     |     |     |     |     |     |     |     |     |

LTS1 +++++++++++++++++++++++++++++++++++++-----------D | | | |
EA1 | | ++++++++++++D | | | | | | | |
EA2 | | | | ++++++++++++D | | | | | |
LTS2 | | | | | | ++++++++++++++++++++++++++++++++++++-----------D
EA3 | | | | | | | | ++++++++++++D
EA4 | | | | | | | | | | ++++++++++++D

The benefit is that developers and users who require a specific feature
get it early while distributors/hosters/software vendors/... have a safe
bet.

johannes

With the recent chaos in the way we begin and ended releases, we would
like to propose a clean way to deal with releases and related decisions: [1]

Really? I think you're blowing this all way out of proportion.

I don't mind a yearly release cycle, as we should get out more releases.
I don't mind a monthly release cycle for .z releases.

What however goes straight against this is:

 * January
      o Decisions which features or changes will be in the next 
        release 

You don't decide on it, you just have to go with what we have.

All the rest you write in the RFC is basically already as we do it.

regards,
Derick

--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug

--001636eef06580573f0495ae312f
Content-Type: text/plain; charset=UTF-8

Hi,

With the recent chaos in the way we begin and ended releases, we would
like to propose a clean way to deal with releases and related decisions: [1]

PHP releases have always been done spontaneously, in a somehow chaotic
way. Individual(s) decided when a release will happen and what could
or could fit in. Release managers role are unclear and the way to
nominate them is not clearly defined either.

The goals of this RFC aim to solve these issues while giving to us,
our users and 3rd parties (distributions, contributors, etc.) more
visibility and the ability to actually have a roadmap, or plan
developments. This RFC aims to define:

• a clear release cycle, periodic
• a transparent decision process for the feature additions, via
  the RFCs and a transparent but anonymous vote
• which changes can be done during a release lifetime (BC breaks,
  bugs fixes, security fixes, etc.)
• a transparent way to choose release managers for a given release
• a better usage of bugs.php.net to track each change, addition,
  bug fixes (security incl.) or other various tasks related to a release
• reduce time between bugs fix releases
• reduce the time to get new features in a release
• suppress BC breaks in bugs fix releases
• feature(s) preview release

thanks for preparing this,

as matthew and andi pointed out, more structure is a good idea. I still think
even with all the things in the RFC in place, we are still very flexible.

Having planned releases and clear processes how to reduce BCs and add transparency was
always a good thing in the projects I worked on.

So I'm definatly in favor of this.

[1] http://wiki.php.net/rfc/releaseprocess

Now I've thought a bit more about it, I'm trying to reply to this with
some constructive comments. I'm reordering it a bit in the response
where it makes sense to do. In a general way, some of the things in here
are done, and IMO it make sense to refine them during the 5.4 process if
we find that things don't work as this theoretical RFC implies.

===== Releases Cycle =====

No feature addition after final x.y.0 release (or x.0.0). Self
contained features or new SAPIs could be carefully considered on a
case by case basis.

Backward compatibility must be respected with the same major releases,
for example from 5.2 to 5.6. Binary compatibility can be broken
between two features releases, f.e. between 5.3 and 5.4:

• x.y.z to x.y.z+1
  • Bugs fixes only (with a room for exceptions on a case by case
    basis and only for small self contained features additions).
  • Extensions support can't be removed (like move them to pecl)
  • Backward compatibility must be kept (internals and userland)
  • ABI/API compatibility must be kept (internals)
• x.y.z to x.y+1.z
  • Bugs fixes
  • New features
  • Extensions support can be ended (moved to pecl)
  • Backward compatibility must be kept
  • API compatibility must be kept (internals and userland)
  • ABI can be broken (internals)
• x.y.z to x+1.0.0
  • Bugs fixes
  • New features
  • Extensions support can be ended (moved to pecl)
  • Backward compatibility can be broken
  • API compatibility can be broken (internals and userland).
  • ABI can be broken (internals)

It is critical to understand the consequences of breaking BC, APIs or
ABIs. It should not be done for the sake of doing it. RFCs explaining
the reasoning behind a breakage and the consequences along with test
cases and patch(es) should help.

The whole section above is really nothing new, but good to write down.

• Yearly release cycle
• 3 years release life cycle
  • 2 years bugs fixes only
  • 1 year security fixes only

==== 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>

==== 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.

==== Timeline example for a release ====

• January
  • 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
• March, 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

• June, 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". I am also thinking
that it might be better to not start in January, but in
September/October so that a new release doesn't come out just before the
summer holidays.

===== 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.

===== Release managers selection =====

The release managers team should be selected in a more transparent
way. The ideal way is again to go through a proposal and a vote. The
same system than the RFCs can obviously be used for the release
managers selection.

The volunteers (a team of two persons) can add propose themselves via
the mailing list and they will be added to a RFC page. A week between
the last call and the vote should be sufficient (given that anyone can
volunteer himself for the next release at any time). The vote takes
place for a week.

Examples:

• John/Fred (yes, no)
• Ted/Georges (yes, no)
• Leon/Nikita (yes, no)

The team with the most votes will be then the RMs for the given
release. One person cannot be a RM for more than one release at the
same time.

Again, one of the questions 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

Sounds like something we might want to look at for feature releases
(from 5.5).

===== 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