Re: Re: Version naming

I think you missed the point there: The rfc only alows these 2 formats <version>1.2.0</version> <version>1.2.0RC1</version> dev/beta etc. are not to be put in the version name - they are package states. Regards Alan anatoly techtonik wrote:

Hello Lukas,

From Friday, December 10, 2004, 12:48:23 AM, you wrote:

LS> Anatoly Techtonik wrote:

Hello pear-dev, It seems, that I've missed all the fun with version naming proposal. Now I see some interesting status convention - CVS commit in one package.xml from

     <version>1.2.0-dev</version>

to

     <version>1.2.0dev</version>

Can smb. quickly enlighten me on the matter, why joined-up writing style was chosen? I thought x.x.x is version and -letters suffix is package status? In natural language people often divide logical concepts by spaces to words, by liparagraphs and so on. Why to have

     preg_match("|\W+|i", $version);
     preg_match("|\w+|i", $version);

instead of

     explode("-", $version);

to get package version and it's status?

LS> you have come late twice .. LS> there is already a new rfc that went through and that would hopefully LS> soon make it into some sort of document: LS> http://pear.php.net/pepr/pepr-proposal-show.php?id=65 This issue wasn't discussed from that I can see in this RFC. It is proposed to make a separate RFC on the issue.

- General discussion on pear-group indicated that no complete agreement could be reached on the 2 controversial points (RC/package state suffixes.), as a result, the conclusion is that they should be proposed as seperate RFC's. - Deleted discussion notes on the RC/package suffix notes.

So, I can offer small draft on this RFC: Some overview first: During developing process packages can pass several stages: 1- proof of concept; 2- preliminary draft; 3- api planning; 4- working draft; 5- api corrections; 6- writing api docs; 7- adding features; 8- testing features; 9- writing user docs; 10- sealing package. 1-4 dev is so-called developing stage (unstable api); 5-7 alpha stage (old api is somehow stable, adding new features); 8-9 beta stage (need testing before using in production environment); 10 (release or RC) for large projects (suitable for production. RC means, that developers sure about stability, but this still should be approved in real production conditions) To distinguish between production and not-well for production packages version can be built as 1.0.0RC1 or 1.0.0-beta and you can just check for '-' to get if package is suitable for production. Stable packages should not have any minuses after releasing. Only pluses. =) Also to get the real package status you can use explode('-', $version); You can ask why not to include RC1 after -? RC1 is not a status in a wide sense. You can set your PEAR repository level to work with only 'beta', 'alpha' packages, but not for 'RC1', 'RC2' types only. If developer sets RC1, that means this version is definitely better, than it's previous release. Developer should not expect any bugs from RC - these must be gone during 'beta' phase. RC is only informative - "we've made all possible to make this package stable, we have a great trust in it, but it should be tested in production environment to ensure that trust" t