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
s the door open for internal changes if they're really needed,
but basically suggests against it.
John Crenshaw
Priacta, Inc.
-Original Message-
From: Dmitry Stogov [mailto:dmi...@zend.com]
Sent: Wednesday, June 01, 2011 7:08 AM
To: Pierre Joye
Cc: PHP internals
Subject: Re: [PHP-
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
37 matches
Mail list logo
