Re: Re: Conditional package dependencies?
| From: | Olivier Guilyardi | Date: | Mon, 11 Jun 2007 18:52:46 +0000 |
| Subject: | Re: Re: Conditional package dependencies? | ||
| References: | 1 2 3 4 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-47012@lists.php.net to get a copy of this message | ||
Gregory Beaver wrote:
> Olivier Guilyardi wrote:
>> If I understand correctly you mean that:
>>
>> - SDG_DS_SQLQuery 1.0.x wouldn't provide any file by its own but depend on:
>> - PHP4
>> - SDG_DS_DBQuery (the old DB-based driver)
>> - SDG_DS_MDB2 (the old MDB2-based driver)
>>
>> - SDG_DS_SQLQuery 1.1.x would provide the new driver's files and depend on:
>> - PHP5
>>
>> - Structures_DataGrid would depend on:
>> - SDG_DS_SQLQuery >= 1.0
>>
>> Then the pear installer would download the 1.0.x version if it detects PHP4, and
>> the 1.1.x or later version otherwise. Is this right?
>
> This is indeed the solution I'm talking about. Be forewarned that this
> will result in some really long version numbers like 1.0.48 and 1.1.94
> if you do a lot of releases :).
Actually, I don't see any reason to release anything else that 1.0 in the 1.0.x
series. Whenever we release a new version of SDG_DS_DBQuery or SDG_DS_MDB2, the
pear installer should install the latest PHP4-compatible version.
And what's wrong with normal numbering starting from 1.1? We could release 1.2,
1.3, etc.. as long as 1.0 is the only release that's not compatible with PHP5.
Am I right?
>
> However, you would need to make sure that code written to use
> SDG_DS_SQLQuery 1.0.x will continue to work *unaltered* if the user
> upgrades the underlying PHP installation to version 5.x from 4.x.
> Otherwise the code is by definition not BC.
Well, if the user calls SDG::bind() and doesn't deal directly with the driver
there should be no BC. But if he instantiates the driver class directly (which
he perfectly has the right to), then he might try to deal with classes that do
not exist anymore starting from SDG_DS_SQLQuery 1.1.
So, I should correct my above list as follow:
- SDG_DS_SQLQuery 1.1.x (and later) would depend on:
- PHP5
- SDG_DS_DBQuery
- SDG_DS_MDB2
That should fix it.
> This means that, for instance, if the 4.x returns PEAR_Error objects,
> you need to have a flag in SDG_DS_SQLQuery that enables exceptions, but
> returns PEAR_Error by default (try/catch internal magic can perform this
> task quite easily)
I see your point... Bad thing indeed. A such flag is bloat-ish IMO. I feel like
there might other similar issues, that might lead us to write obfuscated code.
I'm starting to wonder if it wouldn't be better to simply mark SQL_DS_DBQuery
and SQL_DS_MDB2Query as superseded by SDG_DS_SQLQuery on their respective
homepages and in the manual, the later being PHP5 only.
Anyway all drivers must be manually installed, they are subpackages. So the fact
that SDG depends on a PHP5 driver shouldn't create installation problems on PHP4.
Mark, what's your point of view?
Regards,
--
Olivier