On Jun 2, 2011, at 3:08 AM, Sebastian Bergmann wrote:
> Am 01.06.2011 14:44, schrieb Johannes Schlüter:
>> I mentioned this before: I like the Ubuntu model:
>>
>> * One development branch for the next version
>> * One current version
>> * One "long term" supported version
>
> +1
+1
Regards,
P
> Am 02.06.2011 13:15, schrieb Peter Lind:
>
> Anyway, I'll stop it here, as I doubt I'll convince you of anything
> (and vice versa).
>
> Just one thing to add: thanks for the work on PHP :) Much appreciated.
>
I think/hope that this RFC is a step in the right direction to make the
release pro
On Thu, Jun 2, 2011 at 1:15 PM, Peter Lind wrote:
> On 2 June 2011 13:03, Pierre Joye wrote:
>> On Thu, Jun 2, 2011 at 1:01 PM, Peter Lind wrote:
>>> On 2 June 2011 12:40, Pierre Joye wrote:
>>>
>>> *snip*
>>>
No, it is the same that what we proposed. What we proposed is that
eve
On 2 June 2011 13:03, Pierre Joye wrote:
> On Thu, Jun 2, 2011 at 1:01 PM, Peter Lind wrote:
>> On 2 June 2011 12:40, Pierre Joye wrote:
>>
>> *snip*
>>
>>>
>>> No, it is the same that what we proposed. What we proposed is that
>>> every release is actually a LTS release. What Ubuntu uses works
On Thu, Jun 2, 2011 at 1:01 PM, Peter Lind wrote:
> On 2 June 2011 12:40, Pierre Joye wrote:
>
> *snip*
>
>>
>> No, it is the same that what we proposed. What we proposed is that
>> every release is actually a LTS release. What Ubuntu uses works fine
>> for distros given that it is a distro with
On 2 June 2011 12:40, Pierre Joye wrote:
*snip*
>
> No, it is the same that what we proposed. What we proposed is that
> every release is actually a LTS release. What Ubuntu uses works fine
> for distros given that it is a distro with an insane amount of totally
> unrelated projects they distrib
On Thu, Jun 2, 2011 at 12:08 PM, Sebastian Bergmann wrote:
>> The current version is aimed to give early access to new features, to
>> avoid cases like traits which take years to come out while a bit more
>> conservative users (and maybe distros) may stay on the LTS.
>
> Traits is a really good
On Thu, Jun 2, 2011 at 11:51 AM, Peter Lind wrote:
> On 2 June 2011 10:23, Pierre Joye wrote:
>> On Thu, Jun 2, 2011 at 7:32 AM, Peter Lind wrote:
>>
>>> Sorry for jumping into the thread, but I couldn't help noting that you seem
>>> confused about the distro suggestion. I think Ubuntu was the e
Am 01.06.2011 14:44, schrieb Johannes Schlüter:
> I mentioned this before: I like the Ubuntu model:
>
> * One development branch for the next version
> * One current version
> * One "long term" supported version
+1
> The current version is aimed to give early access to new features, to
> avoid
On 2 June 2011 10:23, Pierre Joye wrote:
> On Thu, Jun 2, 2011 at 7:32 AM, Peter Lind wrote:
>
>> Sorry for jumping into the thread, but I couldn't help noting that you seem
>> confused about the distro suggestion. I think Ubuntu was the example, and
>> there's nothing random at all about their r
Am 02.06.2011 11:36, schrieb David Muir:
> That said, I'm not sure if an LTS is a good idea. One of the biggest
> frustrations for me as a developer is hosts taking forever to upgrade to
> newer versions of PHP. Most hosts I've seen are still on 5.2, and some
> don't seem to have plans of upgradin
On 02/06/11 17:23, Pierre Joye wrote:
> On Thu, Jun 2, 2011 at 7:32 AM, Peter Lind wrote:
>
>> Sorry for jumping into the thread, but I couldn't help noting that you seem
>> confused about the distro suggestion. I think Ubuntu was the example, and
>> there's nothing random at all about their relea
On Thu, Jun 2, 2011 at 7:32 AM, Peter Lind wrote:
> Sorry for jumping into the thread, but I couldn't help noting that you seem
> confused about the distro suggestion. I think Ubuntu was the example, and
> there's nothing random at all about their release process. There are fixed
> timelines and
On Jun 2, 2011 12:46 AM, "Pierre Joye" wrote:
>
> hi Chris
>
> On Thu, Jun 2, 2011 at 12:34 AM, Christopher Jones
> wrote:
> >
> >
> > On 06/01/2011 03:09 AM, Pierre Joye wrote:
> >
> >> URL: https://wiki.php.net/rfc/releaseprocess
> >
> > Pierre,
> >
> > There are some immediately practical thin
hi Chris
On Thu, Jun 2, 2011 at 12:34 AM, Christopher Jones
wrote:
>
>
> On 06/01/2011 03:09 AM, Pierre Joye wrote:
>
>> URL: https://wiki.php.net/rfc/releaseprocess
>
> Pierre,
>
> There are some immediately practical things here. Some things will
> be a large jolt for the community and might b
On 06/01/2011 03:09 AM, Pierre Joye wrote:
URL: https://wiki.php.net/rfc/releaseprocess
Pierre,
There are some immediately practical things here. Some things will
be a large jolt for the community and might be better introduced in
future releases.
Chris
Good:
- Scheduled releases
- U
On Thu, Jun 2, 2011 at 12:10 AM, Zeev Suraski wrote:
>> However, what you refer to is about internals API. We can (and did a
>> lot) break ABI between x.y and x.y+1 and should really avoid breaking API
>> (read: signatures, source compatibility) if possible.
>
> I think we need to clear it up in t
> However, what you refer to is about internals API. We can (and did a
> lot) break ABI between x.y and x.y+1 and should really avoid breaking API
> (read: signatures, source compatibility) if possible.
I think we need to clear it up in the RFC. My take:
- Switch from talking about 'ABI' to 'ext
On Wed, Jun 1, 2011 at 6:47 PM, Dmitry Stogov wrote:
> Before now each major (5.y+1) release introduced API changes.
> We just couldn't introduce literal tables, interned strings, etc without API
> changes.
>
> However such API breaks where invisible for user-land and most extensions,
> they requi
Hi!
There's something between the user level API and the ABI - which is source
level compatibility.
That's a good point. We'd like to keep source-level incompatibilities to
a minimum - especially for simple extensions, not like APC :) - but I
agree it may be hard to maintain at 100% if we d
t; Cc: John Crenshaw; PHP internals
> Subject: Re: [PHP-DEV] Final version, RFC release process
>
> Hi!
>
> > Before now each major (5.y+1) release introduced API changes.
> > We just couldn't introduce literal tables, interned strings, etc
> > without API ch
Hi!
Before now each major (5.y+1) release introduced API changes.
We just couldn't introduce literal tables, interned strings, etc without
API changes.
I think by API there it means PHP-level API, i.e. one exposed to the
user, not binary API exposed to the extensions, which is meant by ABI.
ge-
From: Dmitry Stogov [mailto:dmi...@zend.com]
Sent: Wednesday, June 01, 2011 7:08 AM
To: Pierre Joye
Cc: PHP internals
Subject: Re: [PHP-DEV] Final version, RFC release process
Hi,
In my opinion a restriction "API compatibility must be kept (internals
and userland)" for x.y.z to
Hi,
From a userland perspective, there should be absolutely no feature addition in
a "bugfix" version (x.y.Z+1) : we would see (just like what we see today)
frameworks, apps, or libraries depending on specific bugfix releases, and this
would not make php versioning easier to understand for any
2011/6/1 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.
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
hi,
2011/6/1 Johannes Schlüter :
> On Wed, 2011-06-01 at 13:45 +0200, Ilia Alshanetsky wrote:
>> > This variant is not workable, because there are (in the example) in 2014
>> > *five* branches. Merging between those, manually and automatically is
>> > going to be a major pain. I'd say we all rath
Sounds reasonable.
2011/6/1 Johannes Schlüter :
> On Wed, 2011-06-01 at 13:45 +0200, Ilia Alshanetsky wrote:
>> > This variant is not workable, because there are (in the example) in 2014
>> > *five* branches. Merging between those, manually and automatically is
>> > going to be a major pain. I'd s
On Wed, 2011-06-01 at 13:45 +0200, Ilia Alshanetsky wrote:
> > This variant is not workable, because there are (in the example) in 2014
> > *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 time
> > on fixes a
>> * running the various test suites (phpt, custom real life tests,
>> platform specific tests). Some tests need a day to run
>> * November, Final
>> * Last RC taken as final, golden release (no change between the last RC
>> and the final version)
>
> TBH, I think 6 months is too
On Wed, Jun 1, 2011 at 1:45 PM, Ilia Alshanetsky wrote:
>> This variant is not workable, because there are (in the example) in 2014
>> *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 time
>> on fixes and new
> This variant is not workable, because there are (in the example) in 2014
> *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 time
> on fixes and new features; and not spend more time doing branch merging,
> wh
On Wed, 1 Jun 2011, Internals wrote:
> URL: https://wiki.php.net/rfc/releaseprocess
Comments again-they are mostly similar as before-I was quite annoyed
that I didn't even get feedback on when I sent it last time:
> Example time line with two majors versions
> However it could happen
DEV] Final version, RFC release process
Hi,
In my opinion a restriction "API compatibility must be kept (internals
and userland)" for x.y.z to x.y+1.z is too strict. It just can block
some new features forever.
I would suggest to change "API compatibility must be kept" to "
On Wed, Jun 1, 2011 at 1:12 PM, Pierre Joye wrote:
> hi,
>
> On Wed, Jun 1, 2011 at 1:07 PM, Dmitry Stogov wrote:
>> Hi,
>>
>> In my opinion a restriction "API compatibility must be kept (internals and
>> userland)" for x.y.z to x.y+1.z is too strict. It just can block some new
>> features foreve
hi,
On Wed, Jun 1, 2011 at 1:07 PM, Dmitry Stogov wrote:
> Hi,
>
> In my opinion a restriction "API compatibility must be kept (internals and
> userland)" for x.y.z to x.y+1.z is too strict. It just can block some new
> features forever.
btw, new APIs do not break API or API.
I do not think we
Hi,
In my opinion a restriction "API compatibility must be kept (internals
and userland)" for x.y.z to x.y+1.z is too strict. It just can block
some new features forever.
I would suggest to change "API compatibility must be kept" to "API
backward compatibility must be kept as much as possibl
Hi,
Long due but finally sending the final RFC for the release process.
There a couple of changes since the last time, they are all about
making it more transparent or catch the edge cases. We also got new
proposers on board, we are now basically almost all active devs on
board.
URL: https://wik
38 matches
Mail list logo
