Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85677
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.182 as permitted sender)
Message-ID: <551C6296.40101@gmail.com>
Date: Wed, 01 Apr 2015 14:26:46 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Dennis Birkholz <dennis@birkholz.biz>, internals@lists.php.net
References: <CAH-PCH74+2-S2ySME1X5QW5rA9Jb5=1T+hJ3t1sxHiaTO31RJA@mail.gmail.com> <551BC7CF.3080309@birkholz.biz> <551C44C7.6060108@gmail.com> <551C48AC.3090908@birkholz.biz> <551C4A60.2050805@gmail.com> <551C5045.3010405@birkholz.biz> <551C56E2.8090100@gmail.com> <551C5AFB.7090107@birkholz.biz>
In-Reply-To: <551C5AFB.7090107@birkholz.biz>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] What's our official stance on small self-contained
 additions in a micro version
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> The questions here are:
> * will this code break any code running with PHP before that patch?
> * does this code change the language in any way?

OK, so I think there's a misunderstanding here. What you describing is
exactly my position - enhancements that are a) small and b)
self-contained are OK, others are not OK. This has been the case since
we started the whole format release process thing.

If you agree with that, then our positions are completely the same.
However, it's not what Pierre's (and possibly others) position is - that
position does not ask any questions, it's a blanket ban on any
enhancement, without any consideration or looking into the substance of
the enhancement. If it adds anything that did not exist before, however
minor and safe, it is still banned.

> But then using the x.y.z version schema implies something like semver

No it doesn't. People used versions way before semver was even a thing,
and semver does not owns versioning in any way. There are literally
hundreds if not thousands of projects using this version format without
any relation to semver.  We may reuse the rules semver uses, when it
makes sense to us, but using three-component version does not introduce
any obligation to abide by what semver.org says to the letter.

> Instead we should consider having a stable "PHP-next" nightly release
> that is something like a stabilized master that gets all changes for the
> X.Y+1 release. If you require these little features, you use that, if

Who will be doing that? Who will be doing all the necessary backporting
and maintenance and how it's different from just porting stable changes
to stable version?

-- 
Stas Malyshev
smalyshev@gmail.com