struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Al Sutton" <al.sut...@alsutton.com>
Subject Re: API Compatibility
Date Fri, 22 Feb 2008 19:24:35 GMT
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" <pbenedict@apache.org>
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 <brian@pontarelli.com>
> 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: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message