Re: Re: Proposal for release process (Was: Re:[PHP-DEV]4.1.0)

I think we should be realistic about what we can and cannot pull. Using this approach as the standard release process is simply not going to work - we barely manage an RC branch and a dev branch properly, and having to maintain an old release branch sync'd with bug fixes is not going to be within our reach. In very specific cases, such as the 4.1.0 -> 4.2.0 change, if there are going to be some key bugs in 4.1.0, releasing a 4.1.1 based on 4.1.0 would be in order. Otherwise, though, I would say that we're only toying with a non practical idea :) Zeev At 02:36 14/11/2001, Stig S. Bakken wrote:

Andi Gutmans wrote: At 12:31 AM 11/11/2001 +0100, Stig S. Bakken wrote:

Andi Gutmans wrote:

Jani, I think in theory what you writes makes sense but it just doesn't

work in

the PHP project. (I'm talking about the minor versions coming out of branches). There are always cries to go with HEAD because it's got new goodies (I think it often makes sense) and then people don't want to release a second version out of a branch but want to use HEAD. All in all the release process in the past few years hasn't been

that bad.

I think the timing has been good and we haven't had *that* many

screw-ups.

What I do think we need is a couple of people who will push things

forward

once everyone decides that it is time to branch and start QA; so that things don't linger.

Andi, If we trim down the PHP distribution to not contain as many "goodies", chances are there won't be as many cries for head (no pun intended). The distinction between the second and third digit is basically documenting to the user the level of change in a release.

I didn't quite understand what you mean :) All I said was that if you create a branch say "4.1.0" and you want to release "4.1.x" from that branch later on whilst HEAD has already moved a couple of months you're going to have a hard time doing it. Yes, merging bug fixes into that branch would be more difficult. But certainly possible, _if_ we identify a need for small bugfix releases. The point is that for the person having a problem with a bug in 4.1.0, upgrading to 4.2.0 may be a problem because of all the other changes. In this case, a 4.1.1 release containing only that bug fix would make a lot of sense. I've been in this situation a few times myself, and it's not funny (X is broken in 4.0.1, 4.0.2 fixes X but breaks Y). - Stig -- PHP Quality Assurance Mailing List <http://www.php.net/> To unsubscribe, e-mail: php-qa-unsubscribe@lists.php.net For additional commands, e-mail: php-qa-help@lists.php.net To contact the list administrators, e-mail: php-list-admin@lists.php.net