Re: PECL versioning

Hi Olivier,

For release point, take the version inside package.xml. If you can't, just autogenerate the template.rc according to the package.xml. That way, PECL devs don't have to handle yet another file that they don't understand because they don't know what Windows is.

You're right, I don't want to give PECL devs Windows-specific files either :) but as Pierre noted, package.xml doesn't address the MINFO issue (phpinfo()), which is also a problem.

For dev versioning, if you are using CVS to pull the source, I can see a couple of options: We are supposed to tag a release under CVS when doing a PECL package. You could easily come up with something like: If there is a diff between last official release and HEAD, do last release number + 1 + -dev. Better yet, same version as last release, but appending -snaps20080319-dev to it or something. It might not be accurable, and I might be preparing 2.0-dev instead of 1.5.1-dev. Maybe we can offer a way to force that (that's even true outside of Windows, as there is no package.xml-dev-next-version file)

This is waaaaaaaay too complicated.

Although it is not accurable, it still allows to see that one binary DLL is more recent (meaning version is higher) than an installed dev snapshot. If I'm not outside of the track, tell me, we can maybe take this idea to the next step.

I think what's going to happen is we're going to have to insist that every PECL package defines PHP_*_VERSION in php_*.h, to be honest. And we need to insist that -dev is used there at all times other than during a release. - Steph

Olivier