I don't know where my mind went... sorry, we had patch releases in 1.x :-) On Fri, Feb 22, 2008 at 9:42 AM, Paul Benedict <[EMAIL PROTECTED]> wrote:
> 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] > > > > >
