Re: OpenID and proposed components
| From: | Joshua Eichorn | Date: | Thu, 21 Jun 2007 16:29:57 +0000 |
| Subject: | Re: OpenID and proposed components | ||
| References: | 1 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-47094@lists.php.net to get a copy of this message | ||
We should have a big announcement about PEAR2 on sunday, were still working out what all the rules would be.
But in general its a new channel for php5 only code
All code is prefixed with PEAR2 (so new code for it would be PEAR2_Math_BigInteger not Math_BigInteger2)
There is a new scheme for handling includes
There is a slightly different acceptance method, (voting/approval is moved to beta release with no alpha releases on the public channel)
Were also not quite there infrastructure wise (channel server, pyrus installer) but if your willing to wait a month or so for your first public release you can start targetting PEAR2 now.
-josh
Pádraic Brady wrote:
I haven't heard much about PEAR2 - does anyone have a link to a good summary? What I will do is try an email to the current Math_BigInteger package lead. The only real change to a Math_BigInteger2 would be basic PHP4->PHP5 syntax updates. There is no extra functionality PHP5 offers in this area. Thanks! Pádraic Pádraic Brady http://blog.astrumfutura.com http://www.patternsforphp.com ----- Original Message ---- From: Justin Patrin <papercrane@gmail.com> To: Pádraic Brady <padraic.brady@yahoo.com> Cc: PEAR Dev <pear-dev@lists.php.net> Sent: Thursday, June 21, 2007 3:45:27 PM Subject: Re: [PEAR-DEV] OpenID and proposed components On 6/21/07, Pádraic Brady <padraic.brady@yahoo.com> wrote:At present they depend on a Crypt_Math, but pending feedback I can easily change that to the existing Math_BigInteger package (PHP4).If Math_BigInteger is PHP4 and your package is PHP5 then it's not supposed to depend on it. I'd suggest proposing your Crypt_Math as Math_BigInteger2 (PEAR2). Also remember that in general if you're continuing a package already in PEAR then you shold try to work with the current maintainers of those packages and that a proposal maynot be needed. I'll defer to the Group, though, to set the precedent for PEAR2 as the rules for PEAR2 are not really set as yet, AFAIK. I'd suggest that we allow PHP5 package that replace PHP4 ones as proposals as long as the original maintainer isn't actively working on a PHP5 version.