Added a hack to care of that for 5.2.4.
I see a few possibilities for a future solution to the problem:
1) Include builds from HEAD for only a certain set of known stable
PECL extensions ( APC, uploadprogress, etc ).
2) Include builds from HEAD for all PECL extensions that build, but
put those known stable ones in one tree and the unstable in another.
3) Include only extensions that have a stable release that builds under win32.
4) Include only extensions that have a stable release that builds
under win32 for only a certain set of known stable PECL extensions (
APC, uploadprogress, etc ).
5) Include only extensions that have a stable release that builds
under win32, but put those known stable ones in one tree and the
unstable in another.
Of these, I see (1) or (2) as the easiest to implement, but (3), (4),
or (5) as being a more ideal solution. Or perhaps there is some
solution in the middle that I'm missing.
What sounds good to everyone else?
On 8/21/07, Scott MacVicar <[EMAIL PROTECTED]> wrote:
> These simply dont work:
> Thread - crashes on shutdown
> iisfunc - crashes on shutdown
> SAM - tries to load a file via include during RINIT
>
> I enabled all extensions minus those three and my installation still
> works, those would be the priority.
>
> The following are only avilable in CVS and have never had a stable release:
> ixsfunc
> php_win32scheduler
> php_win32service
>
> There are no doubt more that could be removed but moving the PECL
> extensions into a separate tree in the installer with a stable and
> unstable branch may be an idea. Or remove the ones in beta completely.
>
> Scott
>
> John Mertic wrote:
> > Make a list of what's considered non-stable and I can drop them from
> > the builds for 5.2.4.
> >
> > On 8/21/07, Scott MacVicar <[EMAIL PROTECTED]> wrote:
> >> There is now another 3 extensions added and the broken ones have yet to
> >> see any sort of love to get them working.
> >>
> >> I'm for removing the non stable PECL extensions or at least those that
> >> don't even load, especially before 5.2.4.
> >>
> >> Scott
> >>
> >> John Mertic wrote:
> >>> Hi,
> >>>
> >>> On 7/2/07, Antony Dovgal <[EMAIL PROTECTED]> wrote:
> >>>> On 03.07.2007 00:50, John Mertic wrote:
> >>>>>> If an author would like his extension in the Windows installer then
> >>>> they
> >>>>>> could just ask, would prevent unmaintained and unstable extensions
> >>>>>> included in the build.
> >>>>> But we are shipping them currently in the zip build ( all I'm doing is
> >>>>> repackaging php-5.2.x-win32.zip and pecl-5.2.x-win32.zip )
> >>>> The zip build is php-5.2.x-win32.zip, you merge it with the PECL
> >>>> package (pecl-5.2.x-win32.zip),
> >>>> which I believe is supposed to be completely separate thing and that
> >>>> causes the mess.
> >>> It's separate, but there is nothing telling the end user that some
> >>> extensions ( such as APC, memcache, etc ) are good to use while others
> >>> aren't.
> >>>
> >>>>> so I think the issue would be better dealt with at the PECL level.
> >>>> Well. no doubt it should be dealt on the PECL level (i.e. maintainers
> >>>> should start
> >>>> maintaining their extensions etc.), but that's a bit unrealistic..
> >>> That's why I think that have the same sort of tagging system PEAR uses
> >>> with stable, beta, alpha would help out here tremendously, but like
> >>> you said that's a topic for another thread....
> >>>
> >>>>>> Could the features potentially be grouped into two trees? Core and
> >>>> added
> >>>>>> functionality that can come from PECL?
> >>>>> Originally, I was thinking the same thing, but the consensus was to
> >>>>> make it the way it is currently. I like the two tree approach myself
> >>>>> and switch to that if that what everyone wants to do. But I do
> >>>>> remember the disention is that it seemed to confusing; perhaps
> >>>>> splitting them up based upon stability instead?
> >>>> Not sure I get you correctly (most probably not), but we do have two
> >>>> separate .zip
> >>>> packages for Win32 and I don't remember any complaints about it.
> >>>> To my personal understanding, the point of this thread is: "please do
> >>>> not merge PECL package into the CORE".
> >>>> Just leave it as is, it's separate package and it's not supposed to be
> >>>> included into the official distro
> >>>> (most of those packages should not be built & distributed at all, but
> >>>> that's a topic for another discussion).
> >>> Then let's go with putting the PECL packages in the installer, but a
> >>> separate menu like you mentioned. Like I said I liked that idea from
> >>> the start, but I remember people thought it was too confusing for some
> >>> reason. From my ( and your ) vantage point it makes it much clearer.
> >>>
> >
> >
>
--
--
John Mertic "Explaining a joke
is like dissecting a frog: you
[EMAIL PROTECTED] understand it better,
but the frog dies in the
process."
-Mark Twain
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
