Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:49266
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.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=WiwX2FtNL2MiG8ZZPn6rCM2SFzK7TmDb2cguILlF5tG1oaj6qKj7hBPsxrYXYOsEla
         meST1VWwp/Kq6IkvzFdC+CTP74ypedaoEHvImfhNTOgGJPwoJHnLhGSUoE/VFMeLCiqD
         mezI6eGo2t3uNXtSvZKv8asDij8Dh/HzTUFus=
MIME-Version: 1.0
Sender: tyra3l@gmail.com
In-Reply-To: <alpine.DEB.2.00.1008101611200.29410@kossu.derickrethans.nl>
References: <AANLkTinAy_93RNH85zLpGo11_2eBYBewxg+=KaPicX4e@mail.gmail.com>
	<AANLkTi=Dv3AtH3BiTUgZwBuTLU30AF=3+5rr9aUUVzGG@mail.gmail.com>
	<AANLkTi=o-ssPwwhO3naDC6B55=bD5uRGvUm+L30z8qGr@mail.gmail.com>
	<1281429940.969.2093.camel@guybrush>
	<255073A3-5250-4962-875A-7B2E69E40A48@pooteeweet.org>
	<1281450642.969.2575.camel@guybrush>
	<alpine.DEB.2.00.1008101611200.29410@kossu.derickrethans.nl>
Date: Tue, 10 Aug 2010 17:43:55 +0200
Message-ID: <AANLkTin6kn-YYV3hQYp6H6ZgKb_fnx_2fSFLB0V56eOc@mail.gmail.com>
To: Derick Rethans <derick@php.net>
Cc: =?UTF-8?Q?Johannes_Schl=C3=BCter?= <johannes@schlueters.de>, 
	Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=0016364178a9325487048d7a0009
Subject: Re: [PHP-DEV] Version management (was: Re: [PHP-DEV] 5.4 Alpha?)
From: info@tyrael.hu (Ferenc Kovacs)

--0016364178a9325487048d7a0009
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2010/8/10 Derick Rethans <derick@php.net>

> On Tue, 10 Aug 2010, Johannes Schl=C3=BCter wrote:
>
> > On Tue, 2010-08-10 at 16:20 +0200, Lukas Kahwe Smith wrote:
> > > Is LTS really something we need to provide? Seems to me like this is
> > > something the linux vendors take care of for the most part. Of course
> > > this leaves windows, OSX (and maybe some others).
> >
> > Well, I don't see it as loooooooooooooooooooooooooong term support, but
>
> Using LTS as a term confused me on that one :P
>
> > rather as way to enable quick feature cycles, so that feature releases
> > can move faster than anybody can upgrade to them (ok, that's a bit too
> > fast the, but hope you get the point), while new features can get in
> > production sooner, where wanted.
> >
> > We could also use the names "feature preview release" and "stable
> > release"(=3Dlts) ... which would bring us close to MySQL's model and th=
eir
> > confusing version numbering (MySQL 5.1 is the stable there, then MySQL
> > 5.4 was announced as preview, now MySQL 5.5 is the current preview
> > release, neither 5.4 nor 5.5 are "stable", "GA", though)
>
> I still don't think this is a good idea though. That would me we have
> (as example) 5.2 in LTS, 5.6 as stable and 5.7 in trunk? How much do you
> (at that point) like supporting a 4/5 year old version? Do you hvae that
> much spare time?
>
> I think our current way work pretty well. There is 5.2 which is
> security-fix supported, 5.3 that is supported and trunk/5.4 that's on
> the way to alpha.
>
> Derick
>
>
From the ubuntu wiki:

"A new LTS version is usually released every 2 years. With the Long Term
Support (LTS) version you get 3 years support on Ubuntu Desktop, and 5 year=
s
on Ubuntu Server. There is no extra fee for the LTS version; we make our
very best work available to everyone on the same free terms. Upgrades to ne=
w
versions of Ubuntu are and always will be free of charge."

So with this release policy comes the following terms:
- the releases coming in a timely manner.
- normal release gets support until the next release comes out.
- an LTS release gets support until a pre-defined time interval(and we
promise we will release the next LTS until that time).
- you have an upgrade-path from a version to the next one.
- you have an upgrade-path from an lts version to the next lts.

we could change the interval-s to suit our needs, but with this policy, the
early-adopters could use and test the new features earlier, but the lazy
devs are allowed to upgrade only with the EOL of the LTS.
with the new approach we could release a new major version much faster and
smaller changeset.

I would suggest the 5.3 branch for the first LTS

what are your thoughts about the optimal timeframe for a normal/LTS php
release?

I would prefer 6-12 months for a release, and 2-3 years for an LTS (this is
why we shouldn't start the LTS with the already old 5.2 branch )

Tyrael

--0016364178a9325487048d7a0009--