[PHP-DEV] Re: [PECL-DEV] About that PECL versioning thing
Steph Fox wrote: I discovered tonight that I have full PECL karma, so the secondary question is: does anyone have any objection to my making all (or most... I'd leave the package.xml ones for now) PECL modules fit this versioning model? i'm fine with it, and i already changed pecl-gen / CodeGen_PECL to create compliant code. I didn't roll a new release yet though waiting for the final outcome of this ... -- Hartmut Holzgraefe, Principal Support Engineer . Discover new MySQL Monitoring Advisory features at: http://www.mysql.com/products/enterprise/whats_new.html Hauptsitz: MySQL GmbH, Dachauer Str.37, 80335 München Geschäftsführer: Kaj Arnö - HRB München 162140 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PECL-DEV] About that PECL versioning thing
Pierre Joye wrote: Not sure if the rest affects codegen, do you check the version format itself or do you realy on the pear installer for this task? it is not checked yet, but it is an open TODO item anyway ... -- Hartmut Holzgraefe, Principal Support Engineer . Discover new MySQL Monitoring Advisory features at: http://www.mysql.com/products/enterprise/whats_new.html Hauptsitz: MySQL GmbH, Dachauer Str.37, 80335 München Geschäftsführer: Kaj Arnö - HRB München 162140 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PECL-DEV] About that PECL versioning thing
On Tue, Mar 25, 2008 at 2:13 AM, Steph Fox [EMAIL PROTECTED] wrote: You can checkout pecl module branch PHP_5_2 and see all the symlinked extensions there for PHP_5_2, plus intl... I know that but that does not tell me what you are talking about now. OK you lost me completely. You would rather have no version capability in PECL beyond the module itself? What's so confusing about 'if you have PECL code that is specific to PHP 6 use the PHP_6_0 branch in PECL'? ? I still have no idea what you are talking about. For which build? PHP snapshots or PECL snapshots? releases builds? I also build from CVS, Pierre. It's useful to me to be able to pull out PHP-branch-specific PECL modules from time to time. Yes, but what does that have to do with this RFC (versionning) and the build based on releases instead of CVS? What on earth are you talking about? I wasn't talking about *release* versioning, this RFC is for *all* versioning. You should have the option for PECL development not to affect the existing users of your package, or to have different releases for different versions of PHP (which some - many - PECL devs will need when we look at PHP 6). If you have a PECL module symlinked into PHP 5.3 and PHP 6.0 they will be slightly different versions, and the way things are set up now there is no way to reflect that difference in the module versioning. That's why I asked what you are referring to... snapshots, releases, PHP snapshots, etc. Now it seems that you are talking about PECL snapshots. I don't think it is important if a package is symlinked or not. If a package is in PHP (symlinked, separate module or merge at packaging time), then it will be available in PHP snapshots anyway. For the snapshots, I think we can post post pone the discussions and continue to use what we have in pecl4win (which uses the same branches than PHP). You obviously haven't looked at the source, because pecl4win doesn't use any PECL branches at all. It does or was supposed to last times Edin discussed it. There was a set of branches to be used for each PHP version, but I did not check the code lately. More generally, this RFC is about versionning and package states as large. Can we try to finish it then you can finally do your manual builds at wish. The rest really requires more time and tweaks :) I think you should stop coming out with superior or derogatory comments and blocking my attempts to make minor headway in this mess, and try instead to concentrate on helping build a system that has some chance of working. Soon. Excuse me? What is the problem again? Can you try to stay cool? From the very begining you defined what you like to do right now (after having made some clarifications): 1. Provide DLL per active branche 2. add version info in these DLLs The 2nd point is why you have created the RFC. That's what we should try to finish this dicussion and the RFC. For the 1st point you clearly said that you want it simple and easy as a first step, I hardly follow you right now as you move in every direction about every single need of PECL. And that's exactly what I was trying to avoid, not to block a good move or innovations, but to avoid a chaotic move in many direction without any specs. Please don't take this last sentence badly, it is also valid for me. The problem is that it is very easy in such discussions to be distracted by other topics and forget the initial RFC (versionning). If we don't focus on it and your initial goal, we will waste energy and time to discuss things again and again without any actual results. I'm sorry if you taken any of my answers badly or personally, none of them was meant to hurt you or your ideas. It is a discussion about a RFC and I try to understand what you are asking or discussing. I also hardly try to stay on the topic. Thanks for your understanding, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PECL-DEV] About that PECL versioning thing
On Tue, Mar 25, 2008 at 10:44 AM, Hartmut Holzgraefe [EMAIL PROTECTED] wrote: Steph Fox wrote: I discovered tonight that I have full PECL karma, so the secondary question is: does anyone have any objection to my making all (or most... I'd leave the package.xml ones for now) PECL modules fit this versioning model? i'm fine with it, and i already changed pecl-gen / CodeGen_PECL to create compliant code. I didn't roll a new release yet though waiting for the final outcome of this ... I think you can go ahead with the #define PHP_[...]_VERSION part, we all agree on that already ( I will update the wiki later today). Not sure if the rest affects codegen, do you check the version format itself or do you realy on the pear installer for this task? Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PECL-DEV] About that PECL versioning thing
Hi Pierre, OK you lost me completely. You would rather have no version capability in PECL beyond the module itself? What's so confusing about 'if you have PECL code that is specific to PHP 6 use the PHP_6_0 branch in PECL'? I still have no idea what you are talking about. For which build? PHP snapshots or PECL snapshots? releases builds? I'm totally confused by your confusion :) All of those builds could prioritise an appropriately-named branch. The only one that currently does this is the PHP build (any), for core extensions only. There's no total independence of PHP in PECL because everything's geared towards one or another of the PHP branches anyway. On the other hand, there are a number of PECL modules that manage very well to cover all the bases in a single package that builds against all PHP branches. Those multi-version modules share a problem with the symlinked ones - nowhere to experiment - since CVS HEAD is effectively a release area in both cases. You obviously haven't looked at the source, because pecl4win doesn't use any PECL branches at all. It does or was supposed to last times Edin discussed it. There was a set of branches to be used for each PHP version, but I did not check the code lately. I did. It uses different PHP branches, not different PECL branches - the only exception is for core modules, which are built (from a hard-coded list) as branch-specific PHP extensions rather than as PECL modules. That said, PECL developers don't tend to use PECL branches anyway - the vast majority develop purely in CVS HEAD, which isn't a big problem so long as the code builds against all versions of PHP. From the very begining you defined what you like to do right now (after having made some clarifications): 1. Provide DLL per active branche Actually that would be 'per release branch'. I've no intention of providing PECL release DLLs for development branches - what would be the point? 2. add version info in these DLLs You missed: 3. add version info in the PHP_MINFO section using the same macro. The 2nd point is why you have created the RFC. and 3rd... That's what we should try to finish this dicussion and the RFC. For the 1st point you clearly said that you want it simple and easy as a first step, I hardly follow you right now as you move in every direction about every single need of PECL. And that's exactly what I was trying to avoid, not to block a good move or innovations, but to avoid a chaotic move in many direction without any specs. Please don't take this last sentence badly, it is also valid for me. I don't do this in isolation, Pierre :) The problem is that it is very easy in such discussions to be distracted by other topics and forget the initial RFC (versionning). If we don't focus on it and your initial goal, we will waste energy and time to discuss things again and again without any actual results. I certainly wasted a great deal of time yesterday responding to lengthy emails rather than getting the job done. I don't intend to do the same today. I'm sorry if you taken any of my answers badly or personally, none of them was meant to hurt you or your ideas. It is a discussion about a RFC and I try to understand what you are asking or discussing. I also hardly try to stay on the topic. It's simple. I want to see PECL modules versioned in a standard way. The issues raised concerning this (not all of them on-list) have been: - symlinked modules: We agreed to use the -core tag for these for now. - PHP-version-specific modules: (most likely case: a PECL module in CVS HEAD builds against everything but PHP 6). This is dealt with in package.xml, but we still don't have a way to distinguish a PHP 6-only module either through phpinfo() or on the pecl.php.net download page. However, unless it's a core module, that same code will be used in snaps. That was the bit I was trying to talk about earlier, but the scripts for snaps and bundles (any) would need to be adapted to prioritise the appropriate branch in PECL for my suggestion to work. - versioning rules: You want to use PEAR's versioning structure, and I agree with all of that apart from the -devel and -stable tags... x.0.0 is by definition stable, anything less is by definition pre-alpha unless it has an -alpha tag. However the existing PECL packages don't always use PEAR rules, so we need to adapt a little to the current circumstances while also recommending the PEAR x.x.x structure for new packages. Also, as with PHP, anything other than a release should be tagged -dev, excepting modules that ship with the core (as per temporary measure above). - space for experimental development: This isn't a major problem because a) experimental code shouldn't really be distributed and b) it's already possible to create a non-release branch or branches in PECL for this kind of thing. Just look at SDO :) We need to revisit: core module versioning and
[PHP-DEV] Re: [PECL-DEV] About that PECL versioning thing
Hi Hartmut, I discovered tonight that I have full PECL karma, so the secondary question is: does anyone have any objection to my making all (or most... I'd leave the package.xml ones for now) PECL modules fit this versioning model? i'm fine with it, and i already changed pecl-gen / CodeGen_PECL to create compliant code. I didn't roll a new release yet though waiting for the final outcome of this ... Cool :) thanks! - Steph -- Hartmut Holzgraefe, Principal Support Engineer . Discover new MySQL Monitoring Advisory features at: http://www.mysql.com/products/enterprise/whats_new.html Hauptsitz: MySQL GmbH, Dachauer Str.37, 80335 München Geschäftsführer: Kaj Arnö - HRB München 162140 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PECL-DEV] About that PECL versioning thing
On Tue, Mar 25, 2008 at 3:59 PM, Steph Fox [EMAIL PROTECTED] wrote: I'm sorry if you taken any of my answers badly or personally, none of them was meant to hurt you or your ideas. It is a discussion about a RFC and I try to understand what you are asking or discussing. I also hardly try to stay on the topic. It's simple. I want to see PECL modules versioned in a standard way. The issues raised concerning this (not all of them on-list) have been: Yes, and we have almost everything required to finalize the RFC. It will obviously needs a transition period for all packages to get used to these new versioning rules. About the build themselves (and only the builds, versionning problem is solved, almost), I really need to know what you are going to do. I know that you will provide DLLs but I don't really know how, where and from which sources. Am I right that all you want to do now is to provide DLLs for PECL releases for each released PHP version? Or do you want to do more than that right now? Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PECL-DEV] About that PECL versioning thing
Hi Pierre, About the build themselves (and only the builds, versionning problem is solved, almost), I really need to know what you are going to do. I know that you will provide DLLs but I don't really know how, where and from which sources. Am I right that all you want to do now is to provide DLLs for PECL releases for each released PHP version? Or do you want to do more than that right now? Versioning first. Worry about the next bit later, or I won't have time to do _any_ of it! I'll put up another RFC before I make any moves other than those already discussed. Since I know how now an' all. - Steph Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PECL-DEV] About that PECL versioning thing
On Tue, Mar 25, 2008 at 4:33 PM, Steph Fox [EMAIL PROTECTED] wrote: Hi Pierre, About the build themselves (and only the builds, versionning problem is solved, almost), I really need to know what you are going to do. I know that you will provide DLLs but I don't really know how, where and from which sources. Am I right that all you want to do now is to provide DLLs for PECL releases for each released PHP version? Or do you want to do more than that right now? Versioning first. Worry about the next bit later, or I won't have time to do _any_ of it! ok, as I said I will update the RFC later today. Good to have it finally :) I'll put up another RFC before I make any moves other than those already discussed. Since I know how now an' all. For anything related to builds (outside your immediate needs for manual builds of PECL releases for each PHP release), please hang your horses. I have began to write one for the summer of code and it covers almost everything you need as far as I can say. Thanks for your understanding, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PECL-DEV] About that PECL versioning thing
Hi Pierre, I'll put up another RFC before I make any moves other than those already discussed. Since I know how now an' all. For anything related to builds (outside your immediate needs for manual builds of PECL releases for each PHP release), please hang your horses. I have began to write one for the summer of code and it covers almost everything you need as far as I can say. Thanks for your understanding, Write one what? An RFC? Don't worry, I'm a way off that yet anyway :) - Steph -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PECL-DEV] About that PECL versioning thing
On Sun, Mar 23, 2008 at 3:51 AM, Steph Fox [EMAIL PROTECTED] wrote: Hi all, Since I'm still awake at 3am... Aside from Pierre's arguments in favour of using package.xml to set the extension version (which 3 PECL extensions - two of them Pierre's - do at present), does anyone have any objection to the proposal at http://wiki.php.net/rfc/peclversioning? I'm not in favour of using package.xml to set the version. I'm in favour of allowing package.xml usage. Now, why cross posting, adding a random set of the pecl-dev discussions as comments in the wiki? And the rules about what means a version increment is missing. The wiki is a publication media, the lists are the discussion media.pecl-dev in this case is the right list. As far as I remember, php-src did not want to have per extension versions. However, It is fine to add an information about its version to help the users to know if the pecl releases is newer than the bundled version. Can we please keep the discussions in on list? It is already hard enough to follow everything. I discovered tonight that I have full PECL karma, so the secondary question is: does anyone have any objection to my making all (or most... I'd leave the package.xml ones for now) PECL modules fit this versioning model? Many extensions use branches, I would go with a patch posted to pecl-dev and let the respective maintainers apply it to the active branches. (zip has two branches + php-src). Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PECL-DEV] About that PECL versioning thing
Hello Pierre, Aside from Pierre's arguments in favour of using package.xml to set the extension version (which 3 PECL extensions - two of them Pierre's - do at present), does anyone have any objection to the proposal at http://wiki.php.net/rfc/peclversioning? I'm not in favour of using package.xml to set the version. I'm in favour of allowing package.xml usage. Nobody's attempting to prevent package.xml usage, least of all me! I actually want to extend package.xml to give more information (QA related) so that people have more of a clue about what they're dealing with. E.g. code coverage %, maintenance status, whether the package is of general/special interest (this last mostly for hosting companies) and some kind of grading system. But this is all open to discussion and probably won't happen for a long while. Now, why cross posting, adding a random set of the pecl-dev discussions as comments in the wiki? Because you told me to do that :) I stopped when it became clear nobody was going to put comments on there. And the rules about what means a version increment is missing. We already have three sets of rules for that (PEAR rules, php-src rules, version_compare() rules). Basically if version_compare() can deal with it, it's in - I don't see how any other approach can be justified, since it may mean messing up someone's long-adopted system. As far as I remember, php-src did not want to have per extension versions. php-src needs to decide what's core (and takes the PHP version) and what's not. This isn't going to happen overnight, so I've compromised by not using the -dev tag for symlinked extensions and by applying the RC data to PECL builds only. There are a few other packages that won't get a -dev tag because they haven't been touched since the last (often first) package release, ie they're not under active development. These aren't necessarily stable, but that's a whole separate issue... we need a way to clearly mark orphaned packages, both for pear/pyrus and for pecl.php.net. However, It is fine to add an information about its version to help the users to know if the pecl releases is newer than the bundled version. Can we please keep the discussions in on list? It is already hard enough to follow everything. There haven't been any off-list discussions about this... unless you count my asking permission from various individuals to add versioning to their packages? I discovered tonight that I have full PECL karma, so the secondary question is: does anyone have any objection to my making all (or most... I'd leave the package.xml ones for now) PECL modules fit this versioning model? Many extensions use branches, I would go with a patch posted to pecl-dev and let the respective maintainers apply it to the active branches. (zip has two branches + php-src). This affects 27 symlinked extensions in 5_2 and 21 in 5_3, all of which I have checked out locally. It's a relative non-issue, for the reasons given above. I started work yesterday on extensions where the maintainer has given explicit permission or where I know for sure they're no longer involved in PHP development (Sterling, Tal). Amazingly, fribidi still works after five years of zero interference :) I'll post patches for the rest on a per-maintainer basis over the coming weeks, but I have to say there are a number of PECL packages I believe are long-time orphans. - Steph Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PECL-DEV] About that PECL versioning thing
Steph Fox wrote: Hello Pierre, Aside from Pierre's arguments in favour of using package.xml to set the extension version (which 3 PECL extensions - two of them Pierre's - do at present), does anyone have any objection to the proposal at http://wiki.php.net/rfc/peclversioning? I'm not in favour of using package.xml to set the version. I'm in favour of allowing package.xml usage. Nobody's attempting to prevent package.xml usage, least of all me! I actually want to extend package.xml to give more information (QA related) so that people have more of a clue about what they're dealing with. E.g. code coverage %, maintenance status, whether the package is of general/special interest (this last mostly for hosting companies) and some kind of grading system. But this is all open to discussion and probably won't happen for a long while. This kind of meta-data doesn't belong in a package.xml, but it would make perfect sense to host it through REST on pecl.php.net. Don't forget, package.xml is used by external channels as well, and they have completely different requirements. package.xml is intended to be used by the pear installer to install packages and provide essential metadata only. Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PECL-DEV] About that PECL versioning thing
Hi Steph, On Mon, Mar 24, 2008 at 3:08 PM, Steph Fox [EMAIL PROTECTED] wrote: Hello Pierre, Aside from Pierre's arguments in favour of using package.xml to set the extension version (which 3 PECL extensions - two of them Pierre's - do at present), does anyone have any objection to the proposal at http://wiki.php.net/rfc/peclversioning? I'm not in favour of using package.xml to set the version. I'm in favour of allowing package.xml usage. Nobody's attempting to prevent package.xml usage, least of all me! Can you try to read the history? This is a reply to you, when you say that I'm in favour of using package.xml... I actually want to extend package.xml to give more information (QA related) so that people have more of a clue about what they're dealing with. E.g. code coverage %, maintenance status, whether the package is of general/special interest (this last mostly for hosting companies) and some kind of grading system. But this is all open to discussion and probably won't happen for a long while. I agree with Greg, only the basic info (what we have now) belongs there. Now, why cross posting, adding a random set of the pecl-dev discussions as comments in the wiki? Because you told me to do that :) I stopped when it became clear nobody was going to put comments on there. I never told you to do that. Let me try to summarize: - publish a RFC in the wiki - announce the publication in one list (if possible only one list :) - update the RFC according to the discussions, that can include a section containing To be discussed/being discussed entries Doing so let one jump into the discussions without having to read dozen of mails on many lists (like now) to get an idea of the current RFC status :) And the rules about what means a version increment is missing. We already have three sets of rules for that (PEAR rules, php-src rules, version_compare() rules). Basically if version_compare() can deal with it, it's in - I don't see how any other approach can be justified, since it may mean messing up someone's long-adopted system. It has nothing to do with version_compare, absolutely nothing. What I'm saying is only what PEAR already does successfully since years. It works very well, it is clear and does not allow some random confusing versions like 0.1.0-stable. As far as I remember, php-src did not want to have per extension versions. php-src needs to decide what's core (and takes the PHP version) and what's not. Everything being in php-src is core. No matter what we'll do next month or in 10 years. This isn't going to happen overnight, so I've compromised by not using the -dev tag for symlinked extensions and by applying the RC data to PECL builds only. That makes little sense to me. If we provide snapshots from PECL, they should follow the same rules than all other PECL extensions. If an extension is also available in PHP releases, then the PHP snapshots will provide it as well for the bundled versions. There are a few other packages that won't get a -dev tag because they haven't been touched since the last (often first) package release, ie they're not under active development. Well, if a package has not been touched, it won't be built and the old dll will be kept no? These aren't necessarily stable, but that's a whole separate issue... we need a way to clearly mark orphaned packages, both for pear/pyrus and for pecl.php.net. PEAR already has a nice system for that, I think we can use it as it is now. It has been proven to work very well since years. However, It is fine to add an information about its version to help the users to know if the pecl releases is newer than the bundled version. Can we please keep the discussions in on list? It is already hard enough to follow everything. There haven't been any off-list discussions about this... unless you count my asking permission from various individuals to add versioning to their packages? I'm talking about your post on internals. It is nice to point internals to the RFC and the pecl-dev discussions though. I discovered tonight that I have full PECL karma, so the secondary question is: does anyone have any objection to my making all (or most... I'd leave the package.xml ones for now) PECL modules fit this versioning model? Many extensions use branches, I would go with a patch posted to pecl-dev and let the respective maintainers apply it to the active branches. (zip has two branches + php-src). This affects 27 symlinked extensions in 5_2 and 21 in 5_3, all of which I have checked out locally. It's a relative non-issue, for the reasons given above. It is a non issue as the versions available in the dllinfo is not that useful. But to apply a patch to a set of random branches is not really a good idea even if it works for many extensions. I'll post patches for the rest on a per-maintainer
Re: [PHP-DEV] Re: [PECL-DEV] About that PECL versioning thing
Hi Pierre... interest (this last mostly for hosting companies) and some kind of grading system. But this is all open to discussion and probably won't happen for a long while. I agree with Greg, only the basic info (what we have now) belongs there. Apparently there are technical reasons for that. This would've come out in that later discussion, but now we have it as a 'given' before we start... makes things a little easier for the summer I guess :) And the rules about what means a version increment is missing. We already have three sets of rules for that (PEAR rules, php-src rules, version_compare() rules). Basically if version_compare() can deal with it, it's in - I don't see how any other approach can be justified, since it may mean messing up someone's long-adopted system. It has nothing to do with version_compare, absolutely nothing. What I'm saying is only what PEAR already does successfully since years. It works very well, it is clear and does not allow some random confusing versions like 0.1.0-stable. Neither does version_compare(). The only problem I've found with it is that it doesn't recognize 1.0.0 and 1.0 as the same value, but that's only a problem if you change existing patterns. (Bear in mind that there are existing patterns for everything that ever had a PECL release, which should be honoured if the 'pecl' command is to keep working.) Also, I've found nothing in PECL that deems itself 'stable' at 0.1.0, so I think that's a bit of a red herring. People seem to have been very good about that on the whole. As far as I remember, php-src did not want to have per extension versions. php-src needs to decide what's core (and takes the PHP version) and what's not. Everything being in php-src is core. No matter what we'll do next month or in 10 years. This isn't going to happen overnight, so I've compromised by not using the -dev tag for symlinked extensions and by applying the RC data to PECL builds only. That makes little sense to me. If we provide snapshots from PECL, they should follow the same rules than all other PECL extensions. OK, here's a plan. How about we allow 'core' as a version tag (for use in MINFO and RC stuff only - package.xml obviously won't use it, and PECL package releases shouldn't either). So you'd have a version string like '1.5.0-core' in phpinfo() and in the .dll for core extensions, and in both cases the PHP version information is also available. A $Revision or $Id string in MINFO would also be useful in core extensions, purely from the bug-tracking PoV. This way you can easily see 1) the package release version, 2) whether or not it ships with PHP (and which version), and 3) when the code was last updated. We also avoid Johannes' problem of needing PECL release packages in a PHP release at a time when this isn't an option. If an extension is also available in PHP releases, then the PHP snapshots will provide it as well for the bundled versions. There are a few other packages that won't get a -dev tag because they haven't been touched since the last (often first) package release, ie they're not under active development. Well, if a package has not been touched, it won't be built and the old dll will be kept no? No. We have new PHP versions every now and again... These aren't necessarily stable, but that's a whole separate issue... we need a way to clearly mark orphaned packages, both for pear/pyrus and for pecl.php.net. PEAR already has a nice system for that, I think we can use it as it is now. It has been proven to work very well since years. Feel free to adapt it to PECL :) This affects 27 symlinked extensions in 5_2 and 21 in 5_3, all of which I have checked out locally. It's a relative non-issue, for the reasons given above. It is a non issue as the versions available in the dllinfo is not that useful. But to apply a patch to a set of random branches is not really a good idea even if it works for many extensions. I'm not 'applying a patch to a set of random branches' tsk! I'll post patches for the rest on a per-maintainer basis over the coming weeks, but I have to say there are a number of PECL packages I believe are long-time orphans. Yes, that's a real problem in PECL. One cause was to move dead extensions from php-src to pecl/ instead of a orphaned repository. It also affects only CVS users as long as these packages do not have any pecl.php.net entry (without releases for example). What would be the best way to deal with dead or orphaned extensions? A separate extensions for dead extensions and add a file REAME.ORPHANED for the orphaned extension? I think just ORPHANED, like we already have CREDITS and EXPERIMENTAL. (Elizabeth will disagree - has already - but I really don't see a better way of approaching this.) That brings me to the next problem (we can discuss it in a separate RFC :), but for the record: - dead extension: useless
Re: [PHP-DEV] Re: [PECL-DEV] About that PECL versioning thing
On Mon, Mar 24, 2008 at 6:05 PM, Steph Fox [EMAIL PROTECTED] wrote: We already have three sets of rules for that (PEAR rules, php-src rules, version_compare() rules). Basically if version_compare() can deal with it, it's in - I don't see how any other approach can be justified, since it may mean messing up someone's long-adopted system. It has nothing to do with version_compare, absolutely nothing. What I'm saying is only what PEAR already does successfully since years. It works very well, it is clear and does not allow some random confusing versions like 0.1.0-stable. Neither does version_compare(). The only problem I've found with it is that it doesn't recognize 1.0.0 and 1.0 as the same value, That's a know issue and that's also why we recommend to use the x.y.z form and not the x.y short version. but that's only a problem if you change existing patterns. (Bear in mind that there are existing patterns for everything that ever had a PECL release, which should be honoured if the 'pecl' command is to keep working.) Also, I've found nothing in PECL that deems itself 'stable' at 0.1.0, so I think that's a bit of a red herring. People seem to have been very good about that on the whole. Yes, it is what we call the common sense. However it would be even better to document this common sense so packager (linux distros), new developers and users will know it. OK, here's a plan. How about we allow 'core' as a version tag (for use in MINFO and RC stuff only - package.xml obviously won't use it, and PECL package releases shouldn't either). So you'd have a version string like '1.5.0-core' in phpinfo() and in the .dll for core extensions, and in both cases the PHP version information is also available. A $Revision or $Id string in MINFO would also be useful in core extensions, purely from the bug-tracking PoV. This way you can easily see 1) the package release version, 2) whether or not it ships with PHP (and which version), and 3) when the code was last updated. We also avoid Johannes' problem of needing PECL release packages in a PHP release at a time when this isn't an option. It may do it. $Revision will still be there (as almost every extension provides it) but it is not very useful (see previous mails). As a summay, we have the following cases: 1. a PECL package is now in core and will be maintained only there. The PECL homepage has to say it 2. a PECL package is now in core and will still be maintained in PECL. For each PHP releases, a PECL release could be done as well so the versions can be matched 3. a PECL package is now in core and will still be maintained in PECL. Core and PECL has two completely different roadmaps, I have no idea how to actually solve this case :) We also avoid Johannes' problem of needing PECL release packages in a PHP release at a time when this isn't an option. About merging a PECL release in a PHP release at packaging time (packaging PHP release), if it is possible to detect whether we are building an extension inside php-src or using phpize (via pecl or manually) then it would be possible to add the -core postfix via a simple #ifdef (I'll love to do it for zip). Well, if a package has not been touched, it won't be built and the old dll will be kept no? No. We have new PHP versions every now and again... I obviously meant to do not build it again for a given PHP version. These aren't necessarily stable, but that's a whole separate issue... we need a way to clearly mark orphaned packages, both for pear/pyrus and for pecl.php.net. PEAR already has a nice system for that, I think we can use it as it is now. It has been proven to work very well since years. Feel free to adapt it to PECL :) That's what I partially did earlier (x.y.z+1 , x.y+1.z, x+1.y.z). I'll add the relevant part to the RFC and merge the points we already agreed on. It is a non issue as the versions available in the dllinfo is not that useful. But to apply a patch to a set of random branches is not really a good idea even if it works for many extensions. I'm not 'applying a patch to a set of random branches' tsk! For example HEAD can be a random branch as well. It was not badly meant but only a possible source of errors/confusions. Yes, that's a real problem in PECL. One cause was to move dead extensions from php-src to pecl/ instead of a orphaned repository. It also affects only CVS users as long as these packages do not have any pecl.php.net entry (without releases for example). What would be the best way to deal with dead or orphaned extensions? A separate extensions for dead extensions and add a file REAME.ORPHANED for the orphaned extension? I think just ORPHANED, like we already have CREDITS and EXPERIMENTAL. (Elizabeth will disagree - has already - but I really don't see a better way of approaching this.) ORPHANED may do it as well.
Re: [PHP-DEV] Re: [PECL-DEV] About that PECL versioning thing
re, On Mon, Mar 24, 2008 at 7:05 PM, Steph Fox [EMAIL PROTECTED] wrote: Yes, it is what we call the common sense. However it would be even better to document this common sense so packager (linux distros), new developers and users will know it. Yes, that's the plan. But, one thing at a time... The versionning RFC is the perfect place to describe ... versions :) As a summay, we have the following cases: 1. a PECL package is now in core and will be maintained only there. The PECL homepage has to say it This doesn't make a lot of sense to me - if they're symlinked, changes made in php-src ext/whatever are really going into PECL CVS. will be maintained only there means that no more PECL releases will be done. In this case, a notice should be added to tell the users to do not update or use the pecl package anymore (if they use a younger php version than the one where the extension was bundled). There's no reason there couldn't be a PECL release of a symlinked core package, either (in fact pecl/hash should probably have one following Solar Designer's patch). Or do you mean non-symlinked packages? If so, are there any PECL packages currently in core that are in this situation? It is not about how the CVS works or if it is used at all but if there will have PECL releases or not once the extension is bundled. For the record, what we have (or plan to) now is: - symlink, common case, what we historically did and do - duplicated, how zip works, php-src/ext/zip is a module and is unrelated to pecl/zip, one has to commit to both tree - merge at release time, how phar may work as far as I remember (that's actually my favourite one as it allows one to work only in pecl and does not care too much about php releases in his development) 2. a PECL package is now in core and will still be maintained in PECL. For each PHP releases, a PECL release could be done as well so the versions can be matched This would be the ideal scenario all round, but enforcing it may be problematic! That's scenarii, not something I like to enforce, only an enumaration of existing cases :) 3. a PECL package is now in core and will still be maintained in PECL. Core and PECL has two completely different roadmaps, I have no idea how to actually solve this case :) Isn't that what CVS branches are for? Yes, and how do you define which branch maps to which version? (See my very first reply for a solution, we can do that later :) Well, if a package has not been touched, it won't be built and the old dll will be kept no? No. We have new PHP versions every now and again... I obviously meant to do not build it again for a given PHP version. It doesn't seem to care about mtime anyway, so I was wrong too: http://cvs.php.net/viewvc.cgi/pecl/fribidi/ http://pecl4win.php.net/ext.php/php_fribidi.dll It can be solved later for the snapshots, for the release it is rather easy to do :) For example HEAD can be a random branch as well. It was not badly meant but only a possible source of errors/confusions. No... it won't be, because in all cases where there is symlinking, all affected branches of the same extension will have the same version number - based on the most recent PECL release and tagged with -core. I'm only looking at 5_2, 5_3 and HEAD here, no more than that. I'm not sure to understand what you mean. Do you mean that all affected branches will have the same version like all branches (5.x or HEAD) will have the same version? Or do you mean that each branch can have a version? The later makes more sense to me. I can imagine a 2.x version for HEAD and still having 1.x for 5.x I think just ORPHANED, like we already have CREDITS and EXPERIMENTAL. (Elizabeth will disagree - has already - but I really don't see a better way of approaching this.) ORPHANED may do it as well. Should I start adding these now, where it's very obvious? And should there be some note inside the ORPHANED file to say what the extension needs? Can you post a list in the wiki or to the list so we can validate it first? What a horrible name :) How about pecl_graveyard? Whatever we like as long as it is well documented :) Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PECL-DEV] About that PECL versioning thing
Oooh What a horrible name :) How about pecl_graveyard? or siberia? :) - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PECL-DEV] About that PECL versioning thing
Hi Pierre, Yes, it is what we call the common sense. However it would be even better to document this common sense so packager (linux distros), new developers and users will know it. Yes, that's the plan. But, one thing at a time... OK, here's a plan. How about we allow 'core' as a version tag (for use in MINFO and RC stuff only - package.xml obviously won't use it, and PECL package releases shouldn't either). So you'd have a version string like '1.5.0-core' in phpinfo() and in the .dll for core extensions, and in both cases the PHP version information is also available. A $Revision or $Id string in MINFO would also be useful in core extensions, purely from the bug-tracking PoV. This way you can easily see 1) the package release version, 2) whether or not it ships with PHP (and which version), and 3) when the code was last updated. We also avoid Johannes' problem of needing PECL release packages in a PHP release at a time when this isn't an option. It may do it. $Revision will still be there (as almost every extension provides it) but it is not very useful (see previous mails). I know, but it gives a *bit* of a clue in what would otherwise be a void. As a summay, we have the following cases: 1. a PECL package is now in core and will be maintained only there. The PECL homepage has to say it This doesn't make a lot of sense to me - if they're symlinked, changes made in php-src ext/whatever are really going into PECL CVS. There's no reason there couldn't be a PECL release of a symlinked core package, either (in fact pecl/hash should probably have one following Solar Designer's patch). Or do you mean non-symlinked packages? If so, are there any PECL packages currently in core that are in this situation? 2. a PECL package is now in core and will still be maintained in PECL. For each PHP releases, a PECL release could be done as well so the versions can be matched This would be the ideal scenario all round, but enforcing it may be problematic! 3. a PECL package is now in core and will still be maintained in PECL. Core and PECL has two completely different roadmaps, I have no idea how to actually solve this case :) Isn't that what CVS branches are for? We also avoid Johannes' problem of needing PECL release packages in a PHP release at a time when this isn't an option. About merging a PECL release in a PHP release at packaging time (packaging PHP release), if it is possible to detect whether we are building an extension inside php-src or using phpize (via pecl or manually) then it would be possible to add the -core postfix via a simple #ifdef (I'll love to do it for zip). Cool :) For the RC stuff I just checked whether the path to the extension src included 'pecl' or not. Well, if a package has not been touched, it won't be built and the old dll will be kept no? No. We have new PHP versions every now and again... I obviously meant to do not build it again for a given PHP version. It doesn't seem to care about mtime anyway, so I was wrong too: http://cvs.php.net/viewvc.cgi/pecl/fribidi/ http://pecl4win.php.net/ext.php/php_fribidi.dll These aren't necessarily stable, but that's a whole separate issue... we need a way to clearly mark orphaned packages, both for pear/pyrus and for pecl.php.net. PEAR already has a nice system for that, I think we can use it as it is now. It has been proven to work very well since years. Feel free to adapt it to PECL :) That's what I partially did earlier (x.y.z+1 , x.y+1.z, x+1.y.z). I'll add the relevant part to the RFC and merge the points we already agreed on. Thanks! It is a non issue as the versions available in the dllinfo is not that useful. But to apply a patch to a set of random branches is not really a good idea even if it works for many extensions. I'm not 'applying a patch to a set of random branches' tsk! For example HEAD can be a random branch as well. It was not badly meant but only a possible source of errors/confusions. No... it won't be, because in all cases where there is symlinking, all affected branches of the same extension will have the same version number - based on the most recent PECL release and tagged with -core. I'm only looking at 5_2, 5_3 and HEAD here, no more than that. Yes, that's a real problem in PECL. One cause was to move dead extensions from php-src to pecl/ instead of a orphaned repository. It also affects only CVS users as long as these packages do not have any pecl.php.net entry (without releases for example). What would be the best way to deal with dead or orphaned extensions? A separate extensions for dead extensions and add a file REAME.ORPHANED for the orphaned extension? I think just ORPHANED, like we already have CREDITS and EXPERIMENTAL. (Elizabeth will disagree - has already - but I really don't see a better way of approaching this.) ORPHANED may do it as well. Should I start adding these
Re: [PHP-DEV] Re: [PECL-DEV] About that PECL versioning thing
Steph Fox wrote: Oooh What a horrible name :) How about pecl_graveyard? or siberia? :) - Steph I vote Siberia - after all that's been the joke all along... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PECL-DEV] About that PECL versioning thing
Steph Fox wrote: What a horrible name :) How about pecl_graveyard? siberia -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PECL-DEV] About that PECL versioning thing
Hannes Magnusson wrote: On Sun, Mar 23, 2008 at 3:51 AM, Steph Fox [EMAIL PROTECTED] wrote: does anyone have any objection to the proposal at http://wiki.php.net/rfc/peclversioning? The first step in fixing the core-pecl relationship? \o/ Looks good. But what about extensions that are symlinked to core? Will they need to update their version info during core release cycles? The version number should only change if extension code has been changed. The fact there is a symlink is not really relevent. PHP will have an issue with any extension at PHP release time if the extension code is still marked -dev or -beta. Open question: do we want an extension's version to be the same in its PHP 5.3 and its PHP 6 code base? It obviously shouldn't have a -dev version when distributed with PHP.. Is it up to the RM to hunt those extensions down and make sure the version info is accurate? I'd suggest so. Chris -- Christopher Jones, Oracle Email: [EMAIL PROTECTED]Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/f8jad Follow me: http://friendfeed.com/ghrd -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PECL-DEV] About that PECL versioning thing
Re, will be maintained only there means that no more PECL releases will be done. In this case, a notice should be added to tell the users to do not update or use the pecl package anymore (if they use a younger php version than the one where the extension was bundled). I hear what you're saying, I'm just reluctant to go with it because I'm hopeful this won't be happening for much longer. There's no reason there couldn't be a PECL release of a symlinked core package, either (in fact pecl/hash should probably have one following Solar Designer's patch). Or do you mean non-symlinked packages? If so, are there any PECL packages currently in core that are in this situation? It is not about how the CVS works or if it is used at all but if there will have PECL releases or not once the extension is bundled. For the record, what we have (or plan to) now is: - symlink, common case, what we historically did and do A lot of people don't like symlinking and want to move away from it, so while it's the common case *now* - again, it probably won't be for much longer. - duplicated, how zip works, php-src/ext/zip is a module and is unrelated to pecl/zip, one has to commit to both tree Ouf, that's a bit of a burden... - merge at release time, how phar may work as far as I remember (that's actually my favourite one as it allows one to work only in pecl and does not care too much about php releases in his development) Yes - I believe this was Wez' original intention too. 3. a PECL package is now in core and will still be maintained in PECL. Core and PECL has two completely different roadmaps, I have no idea how to actually solve this case :) Isn't that what CVS branches are for? Yes, and how do you define which branch maps to which version? (See my very first reply for a solution, we can do that later :) I looked it up: quote The only problem is for the snapshots, which version-dev should we use? My plan was to let the developers define which branch matches which version (like MYEXT_1_8 for 1.8-dev for example). It should be also possible to let the developers define which branch should be used for which php versions for the snapshots. /quote I know where you're coming from, but IMHO it would make much more sense to use the existing PHP_*_* branches where the package code is *specific* to a PHP version. There's no good way for the snaps machine to know about 200+ different variations on MYEXT_1_8, and likewise there would also be no good way for a cvs client to grab all the packages for a given PHP branch out of CVS if everyone used differently-named branches to mean that. At present it's mostly the symlinked extensions that use those branches, but pecl/intl's been using PHP_5_2 throughout with no apparent ill effect. pecl4win and snaps currently don't appear to use PECL branches at all, but that's probably because most PECL devs don't (yet)... there's no reason I can see that both couldn't be made to have a handful of named CVS branches override PECL HEAD for the appropriate PHP branch. Given that development work generally should be done in CVS HEAD, and that most packages are coded to run under all current versions of PHP, the only way it makes sense to form any other kind of branch is if: 1. your package is developed solely in CVS HEAD 2. it builds against all target branches of PHP 3. you want to do some private experimenting In such a case the experimental code shouldn't really be made available as a snapshot anyway - snapshots are intended for users, not for developers. The real problem we have is that there's no obvious way to tell if a PECL package *release* is geared to a specific branch - and that's only really a problem because we effectively have two development branches in PHP at present, HEAD and 5_3. Even so, most PECL devs aim to have their code work with both 5_2 and 5_3 (and some go much, much further, as you know.) It can be solved later for the snapshots, for the release it is rather easy to do :) In package.xml, yes - but that information doesn't appear along with the package release info on the site. Having it there would be useful. The later makes more sense to me. I can imagine a 2.x version for HEAD and still having 1.x for 5.x But then we should have a PHP_6_0 branch to host the version-specific 2.x package development... not a couple of hundred differently-named branches for the same purpose :) Snaps should build PHP HEAD (only) against your 2.x and the rest against your 1.x (presumably in PECL HEAD), and both pecl.php.net and package.xml should have the target PHP version clearly marked. If/when PHP 6 supercedes PHP 5 you can put your old HEAD code into the 5_* branch, do a final release from there and ignore it ever after. And once you're working in a branch - you might as well keep it that way and use HEAD for experiments, since nothing's going to be released from there and your target PHP versions are
Re: [PHP-DEV] Re: [PECL-DEV] About that PECL versioning thing
The real problem we have is that there's no obvious way to tell if a PECL package *release* is geared to a specific branch - and that's only really a problem because we effectively have two development branches in PHP at present, HEAD and 5_3. Even so, most PECL devs aim to have their code work with both 5_2 and 5_3 (and some go much, much further, as you know.) We have an easy way to do it for released packages, using package.xml. That's why the PHP version dependency exists. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PECL-DEV] About that PECL versioning thing
We have an easy way to do it for released packages, using package.xml. That's why the PHP version dependency exists. Please read the rest of my post :) - Steph Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PECL-DEV] About that PECL versioning thing
Hi, On Mon, Mar 24, 2008 at 10:00 PM, Steph Fox [EMAIL PROTECTED] wrote: Re, will be maintained only there means that no more PECL releases will be done. In this case, a notice should be added to tell the users to do not update or use the pecl package anymore (if they use a younger php version than the one where the extension was bundled). I hear what you're saying, I'm just reluctant to go with it because I'm hopeful this won't be happening for much longer. There's no reason there couldn't be a PECL release of a symlinked core package, either (in fact pecl/hash should probably have one following Solar Designer's patch). Or do you mean non-symlinked packages? If so, are there any PECL packages currently in core that are in this situation? It is not about how the CVS works or if it is used at all but if there will have PECL releases or not once the extension is bundled. For the record, what we have (or plan to) now is: - symlink, common case, what we historically did and do A lot of people don't like symlinking and want to move away from it, so while it's the common case *now* - again, it probably won't be for much longer. - duplicated, how zip works, php-src/ext/zip is a module and is unrelated to pecl/zip, one has to commit to both tree Ouf, that's a bit of a burden... - merge at release time, how phar may work as far as I remember (that's actually my favourite one as it allows one to work only in pecl and does not care too much about php releases in his development) Yes - I believe this was Wez' original intention too. 3. a PECL package is now in core and will still be maintained in PECL. Core and PECL has two completely different roadmaps, I have no idea how to actually solve this case :) Isn't that what CVS branches are for? Yes, and how do you define which branch maps to which version? (See my very first reply for a solution, we can do that later :) I looked it up: quote The only problem is for the snapshots, which version-dev should we use? My plan was to let the developers define which branch matches which version (like MYEXT_1_8 for 1.8-dev for example). It should be also possible to let the developers define which branch should be used for which php versions for the snapshots. /quote I know where you're coming from, but IMHO it would make much more sense to use the existing PHP_*_* branches where the package code is *specific* to a PHP version. There's no good way for the snaps machine to know about 200+ different variations on MYEXT_1_8, and likewise there would also be no good way for a cvs client to grab all the packages for a given PHP branch out of CVS if everyone used differently-named branches to mean that. Now I'm a bit confused. What are yout talking about now? PHP snapshots or PECL snapshots? releases builds? I can answer to the rest of your post once I know better what you are referring to. I fear that you are making too strong relations between pecl's cvs and PHP's cvs. As I can understand that one may like to have the same branches, I don't want to have to use them. PHP branches do not fit well to pecl development, as you noticed already almost all packages can be built against all php versions. The goal is to have a stable branch and maybe some expiremental branches (they are not really relevant in your case, build a dll for each active PHP branch). Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PECL-DEV] About that PECL versioning thing
Hi Pierre, quote The only problem is for the snapshots, which version-dev should we use? My plan was to let the developers define which branch matches which version (like MYEXT_1_8 for 1.8-dev for example). It should be also possible to let the developers define which branch should be used for which php versions for the snapshots. /quote I know where you're coming from, but IMHO it would make much more sense to use the existing PHP_*_* branches where the package code is *specific* to a PHP version. There's no good way for the snaps machine to know about 200+ different variations on MYEXT_1_8, and likewise there would also be no good way for a cvs client to grab all the packages for a given PHP branch out of CVS if everyone used differently-named branches to mean that. Now I'm a bit confused. What are yout talking about now? PHP snapshots or PECL snapshots? releases builds? You can checkout pecl module branch PHP_5_2 and see all the symlinked extensions there for PHP_5_2, plus intl... I can answer to the rest of your post once I know better what you are referring to. I fear that you are making too strong relations between pecl's cvs and PHP's cvs. I think you just haven't stumbled across that co possibility. It doesn't show up anywhere as an official PECL branch, but it does work. As I can understand that one may like to have the same branches, I don't want to have to use them. PHP branches do not fit well to pecl development, as you noticed already almost all packages can be built against all php versions. The goal is to have a stable branch and maybe some expiremental branches (they are not really relevant in your case, build a dll for each active PHP branch). I also build from CVS, Pierre. It's useful to me to be able to pull out PHP-branch-specific PECL modules from time to time. That said, I'd agree with you completely if it weren't for the differences in PHP 6. As things are, though, I'd imagine a lot of PECL developers could find a use for a PHP_6_0 branch that ships with/is built alongside PHP 6, and leave their otherwise working code in PECL CVS HEAD for the time being. Extension-specific experimental branches aren't really relevant to this discussion because we're focusing on distribution for now. - Steph Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PECL-DEV] About that PECL versioning thing
On Mon, Mar 24, 2008 at 11:10 PM, Steph Fox [EMAIL PROTECTED] wrote: Hi Pierre, quote The only problem is for the snapshots, which version-dev should we use? My plan was to let the developers define which branch matches which version (like MYEXT_1_8 for 1.8-dev for example). It should be also possible to let the developers define which branch should be used for which php versions for the snapshots. /quote I know where you're coming from, but IMHO it would make much more sense to use the existing PHP_*_* branches where the package code is *specific* to a PHP version. There's no good way for the snaps machine to know about 200+ different variations on MYEXT_1_8, and likewise there would also be no good way for a cvs client to grab all the packages for a given PHP branch out of CVS if everyone used differently-named branches to mean that. Now I'm a bit confused. What are yout talking about now? PHP snapshots or PECL snapshots? releases builds? You can checkout pecl module branch PHP_5_2 and see all the symlinked extensions there for PHP_5_2, plus intl... I know that but that does not tell me what you are talking about now. I can answer to the rest of your post once I know better what you are referring to. I fear that you are making too strong relations between pecl's cvs and PHP's cvs. I think you just haven't stumbled across that co possibility. It doesn't show up anywhere as an official PECL branch, but it does work. Again, CVS should be used only for snaphots nothing else. But I don't know what you are referring to. As I can understand that one may like to have the same branches, I don't want to have to use them. PHP branches do not fit well to pecl development, as you noticed already almost all packages can be built against all php versions. The goal is to have a stable branch and maybe some expiremental branches (they are not really relevant in your case, build a dll for each active PHP branch). I also build from CVS, Pierre. It's useful to me to be able to pull out PHP-branch-specific PECL modules from time to time. Yes, but what does that have to do with this RFC (versionning) and the build based on releases instead of CVS? For the snapshots, I think we can post post pone the discussions and continue to use what we have in pecl4win (which uses the same branches than PHP). More generally, this RFC is about versionning and package states as large. Can we try to finish it then you can finally do your manual builds at wish. The rest really requires more time and tweaks :) Cheersm -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PECL-DEV] About that PECL versioning thing
Hi Pierre, Now I'm a bit confused. What are yout talking about now? PHP snapshots or PECL snapshots? releases builds? You can checkout pecl module branch PHP_5_2 and see all the symlinked extensions there for PHP_5_2, plus intl... I know that but that does not tell me what you are talking about now. OK you lost me completely. You would rather have no version capability in PECL beyond the module itself? What's so confusing about 'if you have PECL code that is specific to PHP 6 use the PHP_6_0 branch in PECL'? I can answer to the rest of your post once I know better what you are referring to. I fear that you are making too strong relations between pecl's cvs and PHP's cvs. I think you just haven't stumbled across that co possibility. It doesn't show up anywhere as an official PECL branch, but it does work. Again, CVS should be used only for snaphots nothing else. But I don't know what you are referring to. What do you mean, you don't know what I'm referring to? And why do you say 'Again..'? Do you assume I haven't understood something? It seems more likely to me you haven't read before responding. Again. As I can understand that one may like to have the same branches, I don't want to have to use them. PHP branches do not fit well to pecl development, as you noticed already almost all packages can be built against all php versions. The goal is to have a stable branch and maybe some expiremental branches (they are not really relevant in your case, build a dll for each active PHP branch). I also build from CVS, Pierre. It's useful to me to be able to pull out PHP-branch-specific PECL modules from time to time. Yes, but what does that have to do with this RFC (versionning) and the build based on releases instead of CVS? What on earth are you talking about? I wasn't talking about *release* versioning, this RFC is for *all* versioning. You should have the option for PECL development not to affect the existing users of your package, or to have different releases for different versions of PHP (which some - many - PECL devs will need when we look at PHP 6). If you have a PECL module symlinked into PHP 5.3 and PHP 6.0 they will be slightly different versions, and the way things are set up now there is no way to reflect that difference in the module versioning. For the snapshots, I think we can post post pone the discussions and continue to use what we have in pecl4win (which uses the same branches than PHP). You obviously haven't looked at the source, because pecl4win doesn't use any PECL branches at all. More generally, this RFC is about versionning and package states as large. Can we try to finish it then you can finally do your manual builds at wish. The rest really requires more time and tweaks :) I think you should stop coming out with superior or derogatory comments and blocking my attempts to make minor headway in this mess, and try instead to concentrate on helping build a system that has some chance of working. Soon. - Steph Cheersm -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PECL-DEV] About that PECL versioning thing
On Sun, Mar 23, 2008 at 3:51 AM, Steph Fox [EMAIL PROTECTED] wrote: does anyone have any objection to the proposal at http://wiki.php.net/rfc/peclversioning? The first step in fixing the core-pecl relationship? \o/ Looks good. But what about extensions that are symlinked to core? Will they need to update their version info during core release cycles? It obviously shouldn't have a -dev version when distributed with PHP.. Is it up to the RM to hunt those extensions down and make sure the version info is accurate? -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PECL-DEV] About that PECL versioning thing
Hi, On Sun, 2008-03-23 at 13:01 +0100, Hannes Magnusson wrote: On Sun, Mar 23, 2008 at 3:51 AM, Steph Fox [EMAIL PROTECTED] wrote: does anyone have any objection to the proposal at http://wiki.php.net/rfc/peclversioning? The first step in fixing the core-pecl relationship? \o/ Looks good. But what about extensions that are symlinked to core? Will they need to update their version info during core release cycles? It obviously shouldn't have a -dev version when distributed with PHP.. Is it up to the RM to hunt those extensions down and make sure the version info is accurate? Just removing the -dev in the version number would be wrong (as is symlinking), a Stable PHP release should include stable extensions. Not dev versions of the extension. So one of the ideas is to fetch the last stable extension release for a PHP release, but well, then there's the problem that everybody (people using snaps, people using CVS, ...) end up with different versions which makes QA hard. (not to mention bug hunting trouble with people using the latest release but updated a single extension, ) johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PECL-DEV] About that PECL versioning thing
Hi, The first step in fixing the core-pecl relationship? \o/ That's the basic idea, yes. But what about extensions that are symlinked to core? Will they need to update their version info during core release cycles? It obviously shouldn't have a -dev version when distributed with PHP.. Is it up to the RM to hunt those extensions down and make sure the version info is accurate? Just removing the -dev in the version number would be wrong (as is symlinking), a Stable PHP release should include stable extensions. Not dev versions of the extension. So one of the ideas is to fetch the last stable extension release for a PHP release, but well, then there's the problem that everybody (people using snaps, people using CVS, ...) end up with different versions which makes QA hard. (not to mention bug hunting trouble with people using the latest release but updated a single extension, ) But we already have those problems now. Labelling the version just makes it more obvious that we have those problems :) - Steph johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PECL-DEV] About that PECL versioning thing
On Sun, Mar 23, 2008 at 2:34 PM, Steph Fox [EMAIL PROTECTED] wrote: Hi, The first step in fixing the core-pecl relationship? \o/ That's the basic idea, yes. But what about extensions that are symlinked to core? Will they need to update their version info during core release cycles? It obviously shouldn't have a -dev version when distributed with PHP.. Is it up to the RM to hunt those extensions down and make sure the version info is accurate? Just removing the -dev in the version number would be wrong (as is symlinking), a Stable PHP release should include stable extensions. Not dev versions of the extension. So one of the ideas is to fetch the last stable extension release for a PHP release, but well, then there's the problem that everybody (people using snaps, people using CVS, ...) end up with different versions which makes QA hard. (not to mention bug hunting trouble with people using the latest release but updated a single extension, ) But we already have those problems now. Labelling the version just makes it more obvious that we have those problems :) Exactly. So lets deal with one problem at a time Johannes. But Steph: Your RFC doesn't mention how to deal with the problem. During development the extension should be -dev... so who is responsible to change it back during PHP releases? -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PECL-DEV] About that PECL versioning thing
Exactly. So lets deal with one problem at a time Johannes. But Steph: Your RFC doesn't mention how to deal with the problem. During development the extension should be -dev... so who is responsible to change it back during PHP releases? Most of the core extensions aren't PECL symlinks, so they're not a problem for now - they can use PHP's own versioning while they're in the mothership, it makes as much sense as anything. I'll make a list of the ones that _are_ symlinked... unless someone already has one? then we can see how much of an issue it is or isn't. - Steph -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PECL-DEV] About that PECL versioning thing
OK.. Just removing the -dev in the version number would be wrong (as is symlinking), a Stable PHP release should include stable extensions. Not dev versions of the extension. So one of the ideas is to fetch the last stable extension release for a PHP release, but well, then there's the problem that everybody (people using snaps, people using CVS, ...) end up with different versions which makes QA hard. (not to mention bug hunting trouble with people using the latest release but updated a single extension, ) Temporary halfway-house solution: don't tag the symlinked extensions with -dev for now, just call them 1.0.0 or whatever. We can move to proper versioning for those symlinked ones when we have a way to bring stable PECL packages into core, but at least there'll be a structure already in place that makes that easy. - Steph johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
