I propose this: Major point releases (1.0, 2.0, 3.0) is where Committers: * May add API signatures * May modify API signatures * May remove deprecated API.
Minor point releases (2.0, 2.1, 2.2) is where Committers: * May add API signatures * May not modify API signatures * May deprecate API. Patch point releases (2.1.1, 2.1.2, 2.1.3) is where Committers: * May not add API signatures * May not modify API signatures * May deprecate API. Struts (2000-2006) in series 1.x has held to these rules except for the last, which we never had point releases. The Apache Commons library follows something very similar and as strict, and I believe is the quality/trust/confidence needed for upgrading. Paul On Fri, Feb 22, 2008 at 9:09 AM, Brian Pontarelli <[EMAIL PROTECTED]> wrote: > Piero Sartini wrote: > > Am Freitag, 22. Februar 2008 00:05:53 schrieb Don Brown: > > > >> Yes, you are missing my original point #2 - "We need to be able to do > >> "alpha" releases to get new, experimental features into the community > >> for testing." I need a way to create an alpha release for 2.1 to hand > >> off to our community for feedback, but if all releases require a > >> unique patch version, I'm forced to create 2.1.1, 2.1.2, 2.1.3, etc. > >> > >> Public API changes take a while and lots of feedback to really get > >> right, so going six months without a release is not acceptable, IMO. > >> > > > > If these changes need feedback .. why not put them in alpha releases? > 2.2 > > Alpha1, 2.2 Alpha2, etc > > > > For me, s.th. like this would be great: > > A.B.C.D > > > > D -> Error fixing, security patches, etc > > C -> new features, smaller api changes even incompatible ones > > B -> big changes, large refactorings, new approaches, etc. > > A -> Struts version > > > This would be sub-patch compatibility, which is fine and most tools > currently or could easily support this. That would mean that 2.1.1.0 and > 2.1.1.1 would be compatible, but 2.1.0 and 2.1.1 are not. Therefore, if > your project depended on 2.1.1.0 and transitively depended on 2.1.0.0, > the build would break, as it should. > > -bp > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
