Stefan Neufeind [2004-04-29 09:53 UTC] Hi Alan,
thanks for working this out and putting all the notes and discussion together. Nice that it got assembled just before the Amsterdam-conf :-) I generally agree with your upon the changes mentioned in this RFC. In my eyes there are just a few small things which remain to be worked out:
- Why may you increase y in a "Bug fix only release" if you are at 0.y.z? I think we might also demand to raise z, if there are no new changes. But usually in 0.x you will add a things here and there, so there is always a way to increase y if you really want :-) But that is no "bug fix only" release anymore then.
- It should clearly be pointed out that RC-releases are still beta. But since this is in the original document I believe you'll want to keep that. Just note that it won't get dropped.
- Integration into the complete RFC (after successful voting imho).
Nice work, thank you!
Aidan Lister [2004-04-29 10:41 UTC] Please comment on the version naming standards in regard to major PHP releases.
Specifically, for example, PHP5 Only versions.
I also think all ambiguity should be removed, for example:
....o in pre stable - you can either increase y (in x.y) or z
I'd suggest: only increasing x, and reserve z for (as in stable) new features.
I also think all examples should use X.Y.Z notation.
Excellent work, feel free to disregard my comments if they are stupid :)
Michael Wallner [2004-04-29 16:49 UTC] Reads well, things I'd like to mention, though:
o I don't really like the idea of increasing Y below stable releases just for bug fixes - increasing Z below 1.0.0 will keep things easier and more consistent
o I cannot understand why the first stable release of Package2 has to be of version 2.0.0 and not 1.0.0, it's actually a independent package and what for is Package*2* then, tough
o I don't like the Package-x.y.z-STATE thingy, but that seems to be handled in another RFC...
Mirco Bauer [2004-04-29 18:59 UTC] I fully agree on this RFC except that stable must be >= 1.0
Net_SmartIRC is at 0.5.5p1 and is stable (the project started in 2002), it will not reach 1.0 till its feature complete, though its a stable library (no BC breakages, working API, runs smooth, long time (as daemon ~1 month then the IRC server usually disconnects :-P, runs fine under stress etc)
Daniel Convissor [2004-05-07 15:56 UTC] The Stable Releases section says one should not have a "stable" state for releases pre 1.0.0. What about using "stable" for RC's of post 1.0.0 releases (e.g. 1.3.0RC3)? I don't have strong opinions on this.
Lukas Smith [2004-05-29 07:53 UTC] Could you add something like the following:
"A package version has a "state" (as indicated in the package.xml file), which describes the maturity. The state may be one of "dev", "alpha", "beta", "RC" or "stable" (listed in the order of code maturity). Please note that the state "RC" is achieved by using the state "beta" and appending the version number with "RC" followed by an integer"
Claudio Bustos [2004-06-05 01:44 UTC] - Devel packages could start on 0.0.x. When alpha state is reached, use 0.1.
- Agree with Bauer on stable>=1.0.0
- Stable should be changed to beta or alpha on stables packages for Release Candidate.
- Agree with Lukas on explanation about code madurity. Maybe add a definition for each one could be useful.
Greg Beaver [2004-10-02 15:17 UTC] potential BC definition:
backwards compatibility is defined by documented API at pearweb (pear.php.net/manual). All documented methods contain a signature, and a return value. If a method's signature or return value changes from the documented values at pear.php.net, then BC has been broken.
If a package is not documented, BC is not possible, and the package may not be above "alpha" stability by definition.
Incidentally, package.xml 2.0 provides the ability to assign differing stability levels for API and for package code. This will solve the question of not-feature-complete-but-stable, as this would mean a package stability can be stable, but API alpha. Alternately, if a new package is matching an existing API, the API could be stable, and the package alpha.
For installation purposes, the least stable state should be used for comparison.
|
