Al, The Apache voting system is totally oblivious to version numbers. Example:
1) Build 2.1.0 is put to vote 2) Voting on 2.1.0 fails 3) Build 2.1.1 is put to vote 4) Voting on 2.1.1 succeeds and is released 5) etc. Numbers do not bump based on the voting. Numbers are bumped based on a finished build. Paul On Fri, Feb 22, 2008 at 1:24 PM, Al Sutton <[EMAIL PROTECTED]> wrote: > It sounds good, but my question would be; what happens if a plugin is > deemed > good enough to include in the core?, would this count as an API addition > and > therefore justify a 2.2? > > Al. > > ----- Original Message ----- > From: "Paul Benedict" <[EMAIL PROTECTED]> > To: "Struts Developers List" <dev@struts.apache.org> > Sent: Friday, February 22, 2008 3:42 PM > Subject: Re: API Compatibility > > > >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.0and > >> 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] > >> > >> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
