I don't think. Otherwise we shouldn't have like now 2 versions schemes in parallel : - alpha/beta (in plugins and core 3.0) - milestone/releases candidates (in core 2.X)
For me a version should be Major.Minor.Patch[Mx|RCx]: - Major : * can break backward compatibility - Minor : * don't break backward compatibility (don't remove or modify the behavior of existing features). * Can add new features. * Can fix bugs - Patch : * don't break backward compatibility (don't remove or modify the behavior of existing features). * Cannot add new features. * Can fix bugs -Milestones and Releases Candidates are used to produce new major or minor versions - Milestone (also known as alpha) * Content evolves. * Can break everything (but should keep backward compat for a minor version) * must be shared with few users - Release Candidate (also known as beta) * Content is stable * Fix issues found in Milestones and RCs * Can be shared with early adopters Arnaud On Thu, Mar 5, 2009 at 12:30 AM, Wendy Smoak <[email protected]> wrote: > On Wed, Mar 4, 2009 at 4:12 PM, Olivier Lamy <[email protected]> wrote: > > > I don't really wan't to block a release with nice a new feature for > > only a number :-). > > Do we have development guidelines for what constitutes > major/minor/patch/alpha/beta versions documented? Maybe adding that, > plus a step or note in the release process to review the fixed issues > and make sure the next version number is appropriate would be good. > > -- > Wendy > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Arnaud
