Don Brown wrote:
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.
I think we will have to disagree on this point. From my perspective
these things are mutually exclusive. You can make experimental new
features and changes without breaking compatibility. It still comes down
to being pragmatic about your changes and ensuring things don't break
severely. However, I want to make it clear that I'm NOT advocating never
breaking compatibility. I just want a versioning scheme that ensures
tools can figure it out.
As a separate question, why can't the scheme be changed for Struts 2
specifically? I get a sense that everyone is saying, "don't even think
about changing it because it will never happen." If something isn't
working and there are better ways to handle things, isn't it our jobs as
engineers to fix them?
-bp
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
