Re: RFC: PECL versioning

Hi Pierre,

What do you mean by "Tag the version with -dev at all times except during a package release"?

I would think that's fairly obvious to all. It's what happens in PHP core, for pity's sake.

The meaning of "-dev" is obvious but what do you mean by "Tag"? If you mean adding a "-dev" postfix or if you refer to cvs tag (or other VCS).

Adding a suffix.

About using a recognized versionning structure, it is indeed a very good thing and required. I would like however to go one or steps further. Not as far as PEAR but it would be great to define some basic rules for the x.y.z formats: - Stable can only be >= 1.0.0 - x.y.z+1 bugs fixes, no BC allowed - x.y+2.z features additions, bugs fixes, no BC allowed

I think that's a nice idea, but enforcing it will be a nightmare.

I know what you mean by that but others may not. It will need writing up.

Yes, the idea is to first agree on this addition and then document it in the RFC :)

That's a really bad place to document things. If there are to be separate coding standards for PECL they should be on peclweb and in the pecl module, surely?

About the replace operation in the package.xml, it is also good to do not have it as requirements, it is only a tool that one can use or not.

No, replacing src from package.xml should be illegal IMHO. It makes the assumption that package.xml was part of the equation in the first place, and that's only true if you're using the PECL system. If you're freely building snapshots, package.xml isn't and shouldn't be part of that equation.

It can be part of the equation for the snapshots as well. The same rule applies except that one will update only the package.xml.

Well no, because package.xml was designed to be part of the PECL release mechanism. It doesn't do much outside that scenario. - Steph

Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org