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]
