I think the proposal is great, but I have to quibble about one thing. Call me petty if you wish, but I dislike having second versions of packages with version numbers other than 2. Why?
The only place that could occur was on the 0.*.* - which wasnt to bad.
A package version is identified by three numbers: a.b.c. The way I read it, {a} is the package release. A profound rewrite or a large feature-leap of a package implies an increment of version number {a}.
the document actual avoids defining when {a} should be changed. (it's covered in the guidelines for BC breaking releases.),
{b} is the API version of a package.
This is kind of true - you can add to the API, but not break the old API behavior however..
Under this naming scheme, it'd be possible to have My_Package2 version 3.0.0 which is strange. If there is a difference justifying the change from 2.x.x to 3.x.x, then the package should become My_Package3, so that users can have version 2 and 3 coexist.
I'm not sure where that is illustrated, I dont think any of the examples show moving from 2.*.* -> 3.0.0, the assumption was as previously that 2->3 would involve a package name change.
In other words, the proposed naming scheme in fact defines a version name as three numbers: My_Package{y} a.b.c. What I'm asking is: What's the difference between {y} and {a}?
Nothing (Except when a == 0)
Regards
Alan
Cheers,
Sérgio