# [RFC] Starting 5.3 - Thread: https://externals.io/message/29170 - Original archive: https://news-web.php.net/php.internals/29170 - Started by Marcus Boerger on 2007-05-04T15:07:44+00:00 - Messages: 148 - Page 1 of 6: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/29170.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #29170 — Marcus Boerger — 2007-05-04T15:07:44+00:00 URL: https://externals.io/message/29170#29170 Hello internals, i'd like to start 5.3 development from 5.2.2 and have 5.2.* only have security relevant changes and no new features whatsoever. For the biggest changes i'd like to see the following: 1) Adding PECL/Phar as default extension 2) Add open_filename debug info to streams 3) Add object handler get_debug_info 4) Split `E_STRICT` into `E_STRICT` and `E_DEPRECATED` a more complete list can be seen here: http://oss.backendmedia.com/PhP53 Besides 1) all mentioned action points require an API change. The first point could also be done in 5.2.3. As soon as we start with 5.3 development we also need to find a way how to keep track of unmerged changes in 5.2/5.3. Right now a lot of stuff only happens in 5.2 and eventually gets MFB'ed. An idea is to provide an easy way to send commits to bugs.php.net and have them as new category "merge required". Maybe we can have the commit script create a link for this. comments welcome - but please think before writing & only write if you have something to say Best regards, Marcus --- ## #29171 — Edin Kadribasic — 2007-05-04T15:43:14+00:00 URL: https://externals.io/message/29170#29171 · In reply to: #29170 Hello Marcus, Adding a new branch is a huge pita for people distributing binary extension, including our own Windows build and PECL4WIN sites. So perhaps we should wait with adding a new branch since 5.2 is a really nice release, the php5 that works very well :) I think that adding a Phar to the distribution for 5.2.3 is an excellent idea. I also see no reason to stop adding smaller non-api-breaking features to 5.2.x and wait until we have a more compelling reason (more goodies than those listed in points 2-4) to branch out. Edin Marcus Boerger wrote: > Hello internals, > > i'd like to start 5.3 development from 5.2.2 and have 5.2.* only have > security relevant changes and no new features whatsoever. > > For the biggest changes i'd like to see the following: > 1) Adding PECL/Phar as default extension > 2) Add open_filename debug info to streams > 3) Add object handler get_debug_info > 4) Split `E_STRICT` into `E_STRICT` and `E_DEPRECATED` > > a more complete list can be seen here: > http://oss.backendmedia.com/PhP53 > > Besides 1) all mentioned action points require an API change. The first > point could also be done in 5.2.3. > > As soon as we start with 5.3 development we also need to find a way how > to keep track of unmerged changes in 5.2/5.3. Right now a lot of stuff > only happens in 5.2 and eventually gets MFB'ed. An idea is to provide > an easy way to send commits to bugs.php.net and have them as new category > "merge required". Maybe we can have the commit script create a link for > this. > > comments welcome > - but please think before writing > & only write if you have something to say > > Best regards, > Marcus --- ## #29172 — Antony Dovgal — 2007-05-04T16:08:35+00:00 URL: https://externals.io/message/29170#29172 · In reply to: #29170 > Hello internals, > > i'd like to start 5.3 development from 5.2.2 and have 5.2.* only have > security relevant changes and no new features whatsoever. I'd like to wait for the end of the year (i.e. for the end of PHP4 support period) and then branch off 5_3. We can use this time to make 5_2 as stable as we can and "test" all the new features in HEAD (*). I believe there are a lot of things to do/fix in 5_2 and we should not leave it unattended in favor of 5_3. (*) Yes, I mean everybody should start using HEAD as a development branch and forget that "bah, that Unicode crap again!" attitude. -- Wbr, Antony Dovgal --- ## #29173 — Ilia Alshanetsky — 2007-05-04T16:54:33+00:00 URL: https://externals.io/message/29170#29173 · In reply to: #29170 > Hello internals, > > i'd like to start 5.3 development from 5.2.2 and have 5.2.* only > have > security relevant changes and no new features whatsoever. > > For the biggest changes i'd like to see the following: > 1) Adding PECL/Phar as default extension I really don't think we need phar in core, certainly not enabled by default. If someone can make a good case for including it, I'd love to hear it. > 2) Add open_filename debug info to streams What would this mean for performance and memory usage of file ops? > 3) Add object handler get_debug_info > 4) Split `E_STRICT` into `E_STRICT` and `E_DEPRECATED` Seems like a good idea. +1 So far I don't really see a key reason to move to 5.3, this is a significant change requiring us to maintain an additional branch at least for a few months. This is not a decision we should make lightly, for non-essential reasons. IMHO. Ilia Alshanetsky --- ## #29174 — Marcus Boerger — 2007-05-04T17:32:05+00:00 URL: https://externals.io/message/29170#29174 · In reply to: #29173 Hello Ilia, Friday, May 4, 2007, 6:54:33 PM, you wrote: > > > […] > I really don't think we need phar in core, certainly not enabled by > default. If someone can make a good case for including it, I'd love > to hear it. Easier distributing/deployment of stuff and phar even allows to use the packed files as is from within the package or unpacked without any change. We use phar already for pear. Having the extension version that allows the mentioned untouched unpacking feature would help a lot of people. > > […] > What would this mean for performance and memory usage of file ops? An additional malloc and strcpy on opening and an additional free on closing. We could however limit actual use to --enable-debug builds. > > […] > Seems like a good idea. +1 > So far I don't really see a key reason to move to 5.3, this is a > significant change requiring us to maintain an additional branch at > least for a few months. This is not a decision we should make > lightly, for non-essential reasons. IMHO. > Ilia Alshanetsky Best regards, Marcus --- ## #29175 — Antony Dovgal — 2007-05-04T17:42:57+00:00 URL: https://externals.io/message/29170#29175 · In reply to: #29174 > > […] > > Easier distributing/deployment of stuff and phar even allows to use the > packed files as is from within the package or unpacked without any > change. We use phar already for pear. Having the extension version that > allows the mentioned untouched unpacking feature would help a lot of > people. What's the problem with having it in PECL? I'm sure everybody interested in it can get it working in no more than 10 seconds using `pecl install phar`. -- Wbr, Antony Dovgal --- ## #29176 — Ilia Alshanetsky — 2007-05-04T17:46:44+00:00 URL: https://externals.io/message/29170#29176 · In reply to: #29174 > > […] > > > […] > > Easier distributing/deployment of stuff and phar even allows to use > the > packed files as is from within the package or unpacked without any > change. We use phar already for pear. Having the extension version > that > allows the mentioned untouched unpacking feature would help a lot of > people. Sure, that's why the Phar is there, I don't contest that it is a useful extension, but so are dozens of others inside PECL. To me it does not mean every extension that is at all useful should be included into the standard distro. If anything having in PECL allows for quicker releases and easier upgrade process, since people will mostly compile it in if it is in core, while pecl will 99% of the time be a shared extension. This means built-in version will require a PHP recompile to upgrade, something most people will not do, making them use older, possibly buggy versions. > > […] > > > […] > > An additional malloc and strcpy on opening and an additional free > on closing. We could however limit actual use to --enable-debug > builds. My preference we enable this feature only for debug builds. Ilia Alshanetsky --- ## #29177 — Edin Kadribasic — 2007-05-04T17:49:38+00:00 URL: https://externals.io/message/29170#29177 · In reply to: #29175 Antony Dovgal wrote: > What's the problem with having it in PECL? > I'm sure everybody interested in it can get it working in no more than > 10 seconds using `pecl install phar`. PECL is great, but it does require a build system with increasingly obsolete set of tools (autoconf-2.13, etc.). Having Phar in the main distro will open up a whole new way to distribute PHP applications which would be a great advantage. The current system of distributing a bunch of PHP files has some shortcomings. Edin --- ## #29178 — Ilia Alshanetsky — 2007-05-04T17:54:19+00:00 URL: https://externals.io/message/29170#29178 · In reply to: #29177 Edink, Just like we build snapshots we can create source packages with pre- built configure scripts for the individual PECL extensions. In fact that's something we need to look into anyway. > Antony Dovgal wrote: > > […] > > PECL is great, but it does require a build system with increasingly > obsolete set of tools (autoconf-2.13, etc.). Having Phar in the main > distro will open up a whole new way to distribute PHP applications > which > would be a great advantage. The current system of distributing a bunch > of PHP files has some shortcomings. > > Edin Ilia Alshanetsky --- ## #29179 — Antony Dovgal — 2007-05-04T18:00:55+00:00 URL: https://externals.io/message/29170#29179 · In reply to: #29177 > Antony Dovgal wrote: > > […] > > PECL is great, but it does require a build system with increasingly > obsolete set of tools (autoconf-2.13, etc.). autoconf-2.13 is not required, it's only recommended. Also the same build system is required to build PHP, so this argument looks bogus to me. > Having Phar in the main > distro will open up a whole new way to distribute PHP applications which > would be a great advantage. The current system of distributing a bunch > of PHP files has some shortcomings. -- Wbr, Antony Dovgal --- ## #29180 — Edin Kadribasic — 2007-05-04T18:06:35+00:00 URL: https://externals.io/message/29170#29180 · In reply to: #29179 Antony Dovgal wrote: > > > […] > > autoconf-2.13 is not required, it's only recommended. > Also the same build system is required to build PHP, so this argument > looks bogus to me. PHP source tarballs come with configure scripts pre-built so auto tools (and very old one at that) are not needed. They are for the pecl installs. I really don't understand the objection. We have added the extensions to the core before when we want to promote a certain technology. Edin --- ## #29181 — Antony Dovgal — 2007-05-04T18:09:55+00:00 URL: https://externals.io/message/29170#29181 · In reply to: #29180 > Antony Dovgal wrote: > > […] > > PHP source tarballs come with configure scripts pre-built so auto tools > (and very old one at that) are not needed. They are for the pecl installs. You need only autoconf and it's really easy to install. > I really don't understand the objection. We have added the extensions to > the core before when we want to promote a certain technology. I object because I believe extensions should be moved from core to PECL, not the other way round. If you don't like PECL or think it's too difficult to use, let's make it easy enough for all. -- Wbr, Antony Dovgal --- ## #29182 — Edin Kadribasic — 2007-05-04T18:16:06+00:00 URL: https://externals.io/message/29170#29182 · In reply to: #29181 Antony Dovgal wrote: [snip] > > […] > > I object because I believe extensions should be moved from core to PECL, > not the other way round. > If you don't like PECL or think it's too difficult to use, let's make it > easy enough for all. Its a noble goal, but lets be realistic. Having and extension in the core package is always going to be easier than installing it as an external package. There is also how wide spread usage of something we want to get. I think that Phar is going to be useful only if its universally available in the PHP installs, and I think that would a good thing for PHP. Edin --- ## #29183 — Antony Dovgal — 2007-05-04T18:21:54+00:00 URL: https://externals.io/message/29170#29183 · In reply to: #29182 > Antony Dovgal wrote: > [snip] > > […] > > Its a noble goal, but lets be realistic. Having and extension in the > core package is always going to be easier than installing it as an > external package. Both ways are easy enough for me. Moreover, I think adding an extension using PECL is much more easier than recompiling&reinstalling PHP. > There is also how wide spread usage of something we > want to get. > I think that Phar is going to be useful only if its > universally available in the PHP installs, and I think that would a good > thing for PHP. This is valid for any other PECL module. Most of the extensions we have are useful and good things. -- Wbr, Antony Dovgal --- ## #29184 — Lukas Kahwe Smith — 2007-05-04T19:14:22+00:00 URL: https://externals.io/message/29170#29184 · In reply to: #29177 Edin Kadribasic wrote: > Antony Dovgal wrote: > > […] > > PECL is great, but it does require a build system with increasingly > obsolete set of tools (autoconf-2.13, etc.). Having Phar in the main > distro will open up a whole new way to distribute PHP applications which > would be a great advantage. The current system of distributing a bunch > of PHP files has some shortcomings. Yes, to me the question is only if we want to give the message that software producers should be able to expect phar to be there on 99% of the systems. Thats the only way that phar has a good chance of really taking off as a php code distribution approach. I personally think that it really improves the distribution process a lot to make this widely available. So I would say yes, add it to core, just like we added ext/json because we feel that this is technology people should be able to rely on. regards, Lukas --- ## #29185 — Richard Lynch — 2007-05-04T19:22:40+00:00 URL: https://externals.io/message/29170#29185 · In reply to: #29181 > If you don't like PECL or think it's too difficult to use, let's make > it easy enough for all. How easy is it for an average user on a shared host that needs X, to use pecl to get X, without an intervention by the webhost? I know y'all don't have this issue; But a few zillion PHP developers do. -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? --- ## #29186 — Ilia Alshanetsky — 2007-05-04T19:24:08+00:00 URL: https://externals.io/message/29170#29186 · In reply to: #29184 > Yes, to me the question is only if we want to give the message that > software producers should be able to expect phar to be there on 99% > of the systems. Thats the only way that phar has a good chance of > really taking off as a php code distribution approach. It sounds like the merits of having phar is would only be apparent after it is included in the core and everyone starts using it because of that. This won't happen simply because most software producers can't rely on extensions that are only available in version X. Ilia Alshanetsky --- ## #29188 — Marcus Boerger — 2007-05-04T19:33:24+00:00 URL: https://externals.io/message/29170#29188 · In reply to: #29186 Hello Ilia, Friday, May 4, 2007, 9:24:08 PM, you wrote: > > > […] > It sounds like the merits of having phar is would only be apparent > after it is included in the core and everyone starts using it because > of that. This won't happen simply because most software producers > can't rely on extensions that are only available in version X. So we stop developing PHP 6 immediately, right? Ah no it is the reason people like you don't MFB. Best regards, Marcus --- ## #29189 — Richard Lynch — 2007-05-04T19:33:29+00:00 URL: https://externals.io/message/29170#29189 · In reply to: #29176 > > […] > > My preference we enable this feature only for debug builds. There might be users for whom debug info in production is way more important than raw performance... I dunno how expensive (malloc + strcopy + free) is, but it doesn't seem to this naive reader like it's going to swamp a server, if somebody who knows what they are doing wants that on even in production. I could easily be under-estimating the expense, but it just seems like there's a lot more PHP scripts that need a lot more better debugging code more than they need raw performance. I'm not claiming that having this available will stop any idiots from writing bad code, but it might help a couple smart folks write better code. -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? --- ## #29190 — Antony Dovgal — 2007-05-04T19:35:31+00:00 URL: https://externals.io/message/29170#29190 · In reply to: #29185 > > > […] > > How easy is it for an average user on a shared host that needs X, to > use pecl to get X, without an intervention by the webhost? It's the same for those who don't have root privileges - you can't add an extension without a help from your sysadmin and it does not depend whether the extension is in core or in PECL. -- Wbr, Antony Dovgal --- ## #29191 — Marcus Boerger — 2007-05-04T19:35:50+00:00 URL: https://externals.io/message/29170#29191 · In reply to: #29185 Hello Richard, exactly the point. Most developers here can easily compile PHP on their own and typically never face a situation where that is no option or not possible at all. Believe it or not. Stuff in PECL is not being used. Not by the majority of PHP users that rely on prebuild/preinstalled stuff. best regards marcus Friday, May 4, 2007, 9:22:40 PM, you wrote: > > > […] > How easy is it for an average user on a shared host that needs X, to > use pecl to get X, without an intervention by the webhost? > I know y'all don't have this issue; But a few zillion PHP developers do. > -- > Some people have a "gift" link here. > Know what I want? > I want you to buy a CD from some indie artist. > http://cdbaby.com/browse/from/lynch > Yeah, I get a buck. So? Best regards, Marcus --- ## #29192 — Lukas Kahwe Smith — 2007-05-04T19:36:06+00:00 URL: https://externals.io/message/29170#29192 · In reply to: #29186 Ilia Alshanetsky wrote: > > > > > […] > > It sounds like the merits of having phar is would only be apparent after > it is included in the core and everyone starts using it because of that. > This won't happen simply because most software producers can't rely on > extensions that are only available in version X. No, the point is that if we want to push something, we need to add it sooner rather than later, because there will be a delay anyways. Also simply by putting it into core, we make sure that phar gets into the long terms plans of users (which are then more likely to accept the transition pain, because they know its going to be around and maintained). regards, Lukas --- ## #29193 — Stanislav Malyshev — 2007-05-04T19:36:22+00:00 URL: https://externals.io/message/29170#29193 · In reply to: #29177 > obsolete set of tools (autoconf-2.13, etc.). Having Phar in the main > distro will open up a whole new way to distribute PHP applications which > would be a great advantage. The current system of distributing a bunch > of PHP files has some shortcomings. I'm personally not sure phar is that great way of distributing apps - it's yet another format not supported by standard tools and I don't really see much of an advantage to using it versus just making a package with any of the existing package formats and I see a number of disadvantages - non-standard format, hard to work with packed scripts with available filesystem tools, etc. But that's my opinion and I fully expect some people to hold exactly the opposite opinion. The question is however is phar so important that everybody needs it in the main source? -- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/ --- ## #29194 — Lukas Kahwe Smith — 2007-05-04T19:39:40+00:00 URL: https://externals.io/message/29170#29194 · In reply to: #29193 Stanislav Malyshev wrote: > expect some people to hold exactly the opposite opinion. The question is > however is phar so important that everybody needs it in the main source? Yup, that is indeed the question. Like I said I think it is important enough. regards, Lukas --- ## #29195 — Marcus Boerger — 2007-05-04T19:44:13+00:00 URL: https://externals.io/message/29170#29195 · In reply to: #29193 Hello Stanislav, - you don't need a tool - well php - but hey you probbaly have that tool - you can run phar archives out of the box - untouched - you can extract phar archives and run them - still untouched - you can provide phar archives that do not require a phar extension To your question "is phar so important that everybody needs it in the main source." I think the above means it should. best regards marcus Friday, May 4, 2007, 9:36:22 PM, you wrote: > > […] > I'm personally not sure phar is that great way of distributing apps - > it's yet another format not supported by standard tools and I don't > really see much of an advantage to using it versus just making a package > with any of the existing package formats and I see a number of > disadvantages - non-standard format, hard to work with packed scripts > with available filesystem tools, etc. But that's my opinion and I fully > expect some people to hold exactly the opposite opinion. The question is > however is phar so important that everybody needs it in the main source? > -- > Stanislav Malyshev, Zend Products Engineer > stas@zend.com http://www.zend.com/ Best regards, Marcus --- Next page: https://externals.io/message/29170.md?page=2