Re: PECL versioning

Hi Steph, On Wed, Mar 19, 2008 at 10:42 PM, Steph Fox <steph@zend.com> wrote: > Hi Pierre, > > > > Important sidenote, have you noticed our proposal for the current > > summer of code? It is only an idea, there is thoughts and projects > > behind this proposal. We even have a box to build DLLs on demand. > > No I haven't, but I have asked Wez for access to the build box at omniti. (I > presume you're talking about the same one?) > Where's the proposal? On the GSOC page. There was also a post on internals earlier last year when the possible candidate to help us proposed some patch. Sadly, he disappeared in the mean time in the eZ Publish labyrinth. That's why we moved it to a GSoC project. A student (or more) can definitively be of great help and can be a long term maintainer. > > Can I suggest to document our thoughts in a dedicated section in the > > wiki? And even more important to a) prioritize and b) define who's > > doing what/when. It will help to waste our precious time to make the > > work twice :) > > Sorry, I thought announcing it on the internals list and in IRC was probably > enough - evidently not so :) I did not see any announce on internal about that :) About IRC, well, that's no place to announce anything :-) > > There is only one safe way, the package version. The other > > informations (either in the various headers or the rc) are rarely > > updated or even used. > > That's... not safe either. It's where I'd pick up info for releases, sure, > but it's not safe info for pecl4win/snaps. I made many tests and ask a couple of extensions developer, the best way could be to let them define what to use where. It can work for the snapshots, the releases or custom builds done on demand. We only need to add the necessary info in peclweb (DB, forms, cvs interface to list the branches for a given ext, etc.). The build system can work easily by creating a tree from various sources. That's what did the person I was refering to in the beggining of this mail. It is really flexible and should allow us to provide whatever we need. > > I can image imagine to add -dev to tell the users that he is using a > > snapshot, like what pecl4win provides now. > > pecl4win doesn't actually provide that at all. That's one of the problems > I'm trying to fix :) Pecl4win provides CVS snapshots, that's what I mean. > > It can be in both places. But one would better have to define it in > > the headers and use the definition in the source files (like in MINFO, > > or foo_version()). > > But how do we solve that problem for 215 packages? I did think of putting > something in the coding standards, but it's a bit too late for all of them. It should be at least in the package.xml (it has to be there or a release can't be done). For the snapshots, I think it should be done using what the developers define in their respective extension backends, the branch FOO_1_8 is the 1.8.x branch, the snapshot will use 1.8-dev (only an example). > > The version in the package.xml for the release you are using should be > > the reference. > > Yes, for releases. Again, not for snaps. You probably misunderstood what I'm > saying - if I change the template.rc in the core it will affect both. It should be possible to have one per dll. But that's a low priority, having a release build system up and working and even for only one or many extension would already rock :) > If the sources code contains the correct placeholders, > > they will also used the right version number (using the replace option > > in the package.xml). The only problem is for the snapshots, which > > version-dev should we use? My plan was to let the developers define > > which branch matches which version (like MYEXT_1_8 for 1.8-dev for > > example). It should be also possible to let the developers define > > which branch should be used for which php versions for the snapshots. > > The releases build will use the information provided in the > > package.xml. > > I'm not worried about branches for now - that's Edin's department, or > possible the GSoC department. My only concern is that the information > embedded in a PECL release DLL is correct. I do worry about that and it is what almost all users I met were asking (and developers too). I doubt a lambda PHP user will ever right click on a php extension to get its version. Reading phpinfo is likely to be the way. By the way, what's about adding an extended php -m? To add the version in the 2nd column? That would be great to have! Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org