Re: PECL versioning

On Thu, Mar 20, 2008 at 2:05 AM, Steph Fox <steph@zend.com> wrote: > 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. You misread me. It does address the problem pretty well. One only has to define the replace rule in the package.xml for each required files (or only for the .h if it is done in a cleaner way). That does not help much for the rc but as Olivier said, it should not be hard to automatically generate it out of the package.xml. > > 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. It is not way too complicated. It is possible (and relatively easily) to allow that once the base is in place. > > 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. That is indeed a good solution, and this define can be replaced at package time using the package.xml info (for the releases). For snapshot using cvs (yes that's not your goal but it has to be solved at the same time), it can be manually define, not sure what is the most developer friendly way. I will add my docs to the wiki during the weekend. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org