maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arnaud HERITIER <aherit...@gmail.com>
Subject Re: [VOTE] Release Maven ear plugin version 2.3.2
Date Wed, 04 Mar 2009 23:46:27 GMT
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 <wsmoak@gmail.com> wrote:

> On Wed, Mar 4, 2009 at 4:12 PM, Olivier Lamy <olamy@apache.org> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>


-- 
Arnaud

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message