Hi Brian,
I shared your frustration when I moved a plugin from 2.1.0 to 2.1.1.
Initially I was taken-aback by the significance of the changes to the
PackageConfig and ActionConfig that broke uses of MockConfiguration. I
didn't expect such a large change between minor revisions and was
disappointed there was no attempt to stay backwards compatible. HOWEVER,
within a few minutes I'd seen the Builders and found the comments that
backwards compatibility was broken to ensure immutability of the
objects. It didn't take me long to get over it.
For me the problem is was one of communication:
- I didn't know the change was coming because I generally don't follow
XWork (I blame myself for not seeking release notes);
- I didn't expect such a significant change between 2.1.0 -> 2.1.1, but
as there hasn't been a GA release in the 2.1.x branch it's acceptable
and known that each revision may be largely incompatible with the last.
It's unreasonable to withhold such a change until 2.2 as feedback is
necessary, so within the existing configuration management framework it
seems the correct practice was followed. Sure I'd prefer a numbering
system matched my own, but the current one does work. Sure I'd have
preferred some transitional arrangements, but the hard-change was
technically justified.
In the case of renaming interceptors and results, I think that migration
was managed very well. It was introduced early, transitional
arrangements put in place and it has been well-communicated.
In the case of removing support for EL in struts tags, I think that
migration was managed badly from 2.0.9->2.0.11 and many users were
adversely affected.
With respect to Tools, the continuous build system is the *best* tool
for checking if a contract through a public API has been broken iff
there are test cases and/or a reference versions (eg. showcase) for each
API. I do think its a reasonable assumption that a plugin built
against, say, 2.0.6, will "by definition" execute with 2.0.11. However
I would not expect that before a GA release of the branch, and I would
never warrant that myself that if I released a plugin. I guess that's
your fundamental expectation.
I do think there is a problem of communication in that:
- there is no "reference" plugin that exercises what we're loosely
calling the public APIs
- the release notes are oriented towards users. There's no release
notes for plugin developers
- The plugin developers guide doesn't articulate what is in fact a
public API
With respect to dependency management, there was a specific problem in
that bundled plugins generally referenced a specific struts 2 core
version (eg. 2.0.6) rather than the parent ${pom.version}so they could
build if the latest core API had changed. I believe that's been
rectified, or perhaps it only applied in the non-bundled plugins I've
examined.
cheers,
Jeromy Evans
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.
Don
On 2/22/08, Brian Pontarelli <[EMAIL PROTECTED]> wrote:
Don Brown wrote:
> On 2/22/08, Brian Pontarelli <[EMAIL PROTECTED]> wrote:
>
>> > These two points, put together, will necessarily result in a 2.1.0
>> > release that is drastically different than 2.1.1. I just don't see
>> > any way around that.
>> >
>>
>> Tooling can solve this issue.
>>
>
> How? As I said, it is not possible for Struts releases to be
> compatible across patch versions. How will tooling solve this?
>
I'm confused as to why it is not possible for them to be compatible.
Compatibility is part of software engineering and up to the developers.
Tools can perform static code analysis prior to releasing a patch
version and determine if APIs have changed. I would envision this type
of process:
1. Everyone tries their best not to bork 2.1.x
2. The release manager for 2.1.2 (for example) runs the tool to check
public APIs against the 2.1.1 tag and trunk in SubVersion.
3. If the tool passes or the errors seem acceptable to the release
manager, they do the release.
4. If the tool finds errors and the errors look bad, release manager
halts release and tells developer that made said changes to fix them.
Am I missing something?
-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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
