Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:52674
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain prohost.org designates 209.85.214.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <BANLkTimKFHuOspMz0RKQQtgivhjYDQDjfQ@mail.gmail.com>
References: <BANLkTim2Tbw+9egfrmrYfeZfNNwYWcg4dg@mail.gmail.com>
	<alpine.DEB.2.02.1106011230270.9040@whisky>
	<BANLkTinC-yoaaGN0V-eeTgeAD9Hm8Qarcw@mail.gmail.com>
	<1306932263.1952.112.camel@guybrush>
	<BANLkTimKFHuOspMz0RKQQtgivhjYDQDjfQ@mail.gmail.com>
Date: Wed, 1 Jun 2011 15:55:30 +0200
Message-ID: <BANLkTimRBqS=KRp4DWwcia-xwMX4xN8aKg@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>
Cc: =?ISO-8859-1?Q?Johannes_Schl=FCter?= <johannes@schlueters.de>, 
	Derick Rethans <derick@php.net>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Final version, RFC release process
From: ilia@prohost.org (Ilia Alshanetsky)

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=FCter <johannes@schlueters.de>:
>> On Wed, 2011-06-01 at 13:45 +0200, Ilia Alshanetsky wrote:
>>> > This variant is not workable, because there are (in the example) in 2=
014
>>> > *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 tim=
e
>>> > on fixes and new features; and not spend more time doing branch mergi=
ng,
>>> > 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
>