Joe Orton wrote:
mod_shmap would be useful at least in modules/test so I can write some perl-framework tests for mod_socache!
OK, I'll think about doing that. The m4/dsp/NWGNU wizardry required makes me tired just thinking about it, though. :-) In the meantime, I think they compile again against the latest API.
Ah, I was waiting for Ruediger to ask ;)
Ho ho ho -- yes, he and Jim have caught me out on too many things to count.
Personally I think it is redundant maintaining fine-grained API versions across changes in unreleased code. Also, if we are going to API version, arguably it should be done by bumping the provider version. But really, I don't care ;)
Personally, I'd have to agree with you in principle about maybe not needing to track unreleased code so carefully. Interesting thought about provider versions. I wonder if there are other providers elsewhere in trunk which we should really bump.
Personally, I don't think it's a big enough deal to repaint the bikeshed. It's an API for module developers, so, if someone gets confused with mod_so, what's the worst that could happen? <cue disaster movie>
Well, there is that. If no one seems to think mod_so and mod_socache* conflict name-wise, I'll just hush up permanently on this point. Cheers, Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
