Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:50464
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.42 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:cc:content-type;
        b=J+2cCwerjus8qJW6zeagWGZJ047Ka4tk1V+QJtoSr2aNDanLmFsrHF0stM2LYAU36J
         SHI10YVRNy6n2Uuavr/wAqoH7TxdOMWK2PT+3Mx9ZWBa1KQa62M/O18S5LteLNUH9xfR
         QVN/exlnUWxsXXKwo+FItzytudZAu5zG6Ba7w=
MIME-Version: 1.0
Sender: tyra3l@gmail.com
In-Reply-To: <AANLkTi=Lqki0nY2wgKRafTBGinPZZ+VLqkHagXzyJiMq@mail.gmail.com>
References: <AANLkTi=ox5uUvEpo8ZuegpTPJLiS353Oqtud1WFGOPUT@mail.gmail.com>
	<1290504719.2294.251.camel@guybrush>
	<AANLkTi=Lqki0nY2wgKRafTBGinPZZ+VLqkHagXzyJiMq@mail.gmail.com>
Date: Tue, 23 Nov 2010 20:34:05 +0100
Message-ID: <AANLkTimrd_5do=3PLB4w1jBNzzO0LBY4Jvqftjqeda7X@mail.gmail.com>
To: Ilia Alshanetsky <ilia@prohost.org>
Cc: =?UTF-8?Q?Johannes_Schl=C3=BCter?= <johannes@schlueters.de>, 
	Felipe Pena <felipensp@gmail.com>, internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001636284dbeb220ec0495bd7466
Subject: Re: [PHP-DEV] [RFC] Release Process
From: info@tyrael.hu (Ferenc Kovacs)

--001636284dbeb220ec0495bd7466
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2010/11/23 Ilia Alshanetsky <ilia@prohost.org>

> I think support 5 or even 3 parallel versions will be highly
> impractical and extra-ordinarily challenging. I think we need a plan
> that limits us to 2 versions and perhaps a 3rd one for critical
> security fixes only.
>
> 2010/11/23 Johannes Schl=C3=BCter <johannes@schlueters.de>:
> > Hi,
> >
> > On Mon, 2010-11-22 at 23:21 -0200, Felipe Pena wrote:
> >> 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 decision=
s:
> [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 bein=
g
> > 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 saf=
e
> > bet.
> >
> > johannes
> >
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
You can't expect the users to switch to the new major version as soon as it
comes out. They have to either migrate their codebase, and sadly they will
wait(at least me and my collegues/friends do this) one or two micro/build
version bump, usually the new major/major.minor version is stable enough.

So if we want to support "equally" 2 major version concurrently, I can't se=
e
how can we make it through supporting 4 branches (oldmajor.last,
oldmajor.current, newmajor.last, newmajor.current)

or we can make "unequal" or "favored" branches:
- either an early adopter vs lts sytem like ubuntu does, but they have 4
supported version at a time also
https://wiki.ubuntu.com/LTS
but I don't know how to mix LTS and php, because they release "shared
nothing" versions, while the php versions does share a common codebase
through their major version, so we can't plan beforehand that what version
will be the nextlts before getting there like the ubuntu guys can. :/

- or stopping the development on the oldmajor version (I mean no new minor
version for the oldmajor, only micro/build bugfix releases)
with that modification, the multiple major version would be like this:
http://wiki.php.net/rfc/releaseprocessalternatives

what do you think?

Tyrael

--001636284dbeb220ec0495bd7466--