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.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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
