Re: Re: Version naming

Anatoly Techtonik wrote:

     <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.

Actually no .. the main purpose of the RFC was to remove the state from the version name alltogether

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.

now you are taking things away from the version naming topic onto a much larger scope ...

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)

Making this a fixed RFC makes no sense. We have packages coming from all sorts of different backgrounds which means they evolve differently. It may make sense to have something like this as part of the developers guide. Having a list of requirements before being able to go stable might however make sense. But finding an agreement on this will be quite hard as this will pit the two camps: unemployed students against professionals who actually have to work against eachother once again (ok I am simplifying things a bit here). But suffice it to say that internals hasnt managed to find a fixed line between Rasmus's "if it does anything useful for anyone its good code" and the opposing views .. and I doubt we will here. regards, Lukas