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]
