Mailing-List: contact dev-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Developers List" <dev@struts.apache.org>
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <436d9a250802211432i7e6adbdese302edb6f6d627f6@mail.gmail.com>
Date: Fri, 22 Feb 2008 09:32:51 +1100
From: "Don Brown" <mrdon@twdata.org>
To: "Struts Developers List" <dev@struts.apache.org>
Subject: Re: API Compatibility
In-Reply-To: <47BDF90D.9090300@pontarelli.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <47BCAB75.2000409@pontarelli.com>
	 <436d9a250802201457y12968309u3ff3fef26f2c2396@mail.gmail.com>
	 <47BD954B.6050305@pontarelli.com>
	 <436d9a250802211256r6b9235ffn1e4d520f3fdcc08b@mail.gmail.com>
	 <47BDE9A9.7090007@pontarelli.com>
	 <436d9a250802211335o75a9a284p690d0eaa3480ca6@mail.gmail.com>
	 <47BDF367.3040800@pontarelli.com>
	 <436d9a250802211411x216d3102r47d6fbe07062af8b@mail.gmail.com>
	 <47BDF90D.9090300@pontarelli.com>

Here are my two points:
 1. Our current versioning scheme requires patch versions for all
releases, regardless of quality
 2. We need to be able to do "alpha" releases to get new, experimental
features into the community for testing

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.

As for your other point about dependencies, well, that problem goes
away once the convention plugin is bundled with Struts, because it
will then have the same version number and will necessarily be
compatibility with its counterparts in that release.

As for third-party plugins, yes, that is an issue, but I don't see how
it is any different than any other library.  My app depends on
Velocity 1.5, but a library I use depends on Velocity 1.4, so problems
could arise.  We have this all the time in the projects I work on, so
I don't see how Struts is unique here.

Don


On 2/22/08, Brian Pontarelli <brian@pontarelli.com> wrote:
>
>  Don Brown wrote:
>  > Well said, and I completely agree.  My original point is your point #1
>  > just isn't possible with the current versioning scheme.  Because every
>  > release gets its own patch number, regardless of quality or API
>  > changes, it can't be counted on, and really, I don't see any solution
>  > other than creating a big matrix of releases for users to somehow
>  > navigate the sea of releases to understand which are compatible with
>  > the other.
>  >
>
> I agree with you on that. It is difficult. However, it doesn't mean that
>  a person or tool couldn't check the public APIs for changes prior to
>  doing a release. The release would not ever occur and remain in
>  -SNAPSHOT until those broken APIs are fixed.
>
>
>   From the other thread:
>
>  > I do agree we need to be much better about how much of our API we
>  > expose to developers, but I think the question of public vs private
>  > API goes beyond the Java semantics and into what a typical Struts user
>  > will encounter.   Unless you are a plugin or framework developer, it
>  > would be very rare for you to be creating configuration objects, so
>  > yes, while these are technically public, I'd certainly call them more
>  > private than, say, the Action interface.
>
>  It is actually more complex than I think you realize. Here is another dependency graph that reveals a really bad issue:
>
>
>  Project A -> struts 2.0.6
>
> Project A -> library B
>  Project A -> library C
>
>  library B -> convention-plugin 2.0.6 -> struts 2.0.6
>
>  library C -> struts 2.1.1
>
>  This graph is broken because the build will decide that 2.1.1 is the latest and most correct version of Struts to use and put that in the classpath. However, the API changes in 2.1.1 break the convention plugin. BUT struts 2.1.1 doesn't depend on the convention plugin 2.1.1 and therefore the build is incapable of warning the user that things are broken and cannot manage this graph correctly.
>
>  So, any public APIs need to be managed and when you introduce transitive dependencies, things get complex. Applications will break, even if they don't use those public APIs directly.
>
>
>  -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