:21 PM
Subject: Re: API Compatibility
Al,
The Apache voting system is totally oblivious to version numbers. Example:
1) Build 2.1.0 is put to vote
2) Voting on 2.1.0 fails
3) Build 2.1.1 is put to vote
4) Voting on 2.1.1 succeeds and is released
5) etc.
Numbers do not bump based on the voting
2008/2/23, Al Sutton [EMAIL PROTECTED]:
So what happens if a plug-in is added to the core (e.g. a YUI and/or GWT
plugin to compliment the dojo one), does that necessitate a 2.2?
This is The Good Question :-)
As I wrote a lot of time before, IMHO every plugin should be treated
as a different
It doesn't help your argument to use Maven as an example :) I think
it is pretty straight forward - all plugins have versions, only the
bundled plugins are versioned/released along with the rest of Struts
to make it simpler. If we gave each plugin its own version, which we
did with Struts 1, it
Wow what a long thread and all in the night :-) (well, at least for Europe).
Sincerely I don't see the problem of changing the name of Struts 2.1.x to
Struts 3.0.x. It's just a version name change.
IMHO if you change the API (read: public, protected and package-friendly
members) instead of
Developers List dev@struts.apache.org
Sent: Friday, February 22, 2008 8:08 AM
Subject: Re: API Compatibility
Wow what a long thread and all in the night :-) (well, at least for
Europe).
Sincerely I don't see the problem of changing the name of Struts 2.1.x
to
Struts 3.0.x. It's just a version name
2008/2/22, Al Sutton [EMAIL PROTECTED]:
I see where you're coming from, but I really don't think the leap from
S2.0
to the current S2.1 is anywhere near the leap from S1 to S2
+1, in fact I think (always it's my humble opinion) that putting Webwork
under the Struts 2 name was a *stupid*
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
Before you start such a discussion, I would suggest that you take the time
to look back, in the archives, through the several years worth of
discussions in that got us to the point we're at today, so that you _fully_
understand the context and the reasoning behind the scheme that we have now.
I
Al Sutton wrote:
Just so we're all on the same page, can I put forward the following as
a version numbering plan which would seem to reflect most peoples views;
2.0.x - New releases shouldn't alter the public API unless absolutley
neccessary (e.g. something is a security risk).
2.1.x
Antonio Petrelli wrote:
Wow what a long thread and all in the night :-) (well, at least for Europe).
Sincerely I don't see the problem of changing the name of Struts 2.1.x to
Struts 3.0.x. It's just a version name change.
IMHO if you change the API (read: public, protected and package-friendly
Al Sutton wrote:
Antonio,
I see where you're coming from, but I really don't think the leap from
S2.0 to the current S2.1 is anywhere near the leap from S1 to S2,
hence why I'm in favour of the 2.1 because I feel it reflects that
although there are some changes, many of the core concepts are
2008/2/22, Brian Pontarelli [EMAIL PROTECTED]:
In order to support the current model you would need to tell tools like
Savant and Ivy that 2.1.0 is not compatible with 2.1.1 but 2.1.1 is
compatible with 2.1.2. In essence you would need a file that lists the
compatibility that those tools
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
This one looks good a good resource. Sun also has one here:
http://java.sun.com/docs/books/jls/second_edition/html/binaryComp.doc.html
Section 13.4 of the java language specification covers compatibility
stuff. Sun also has some good information about versioning of JAR files
and distributed
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
I don't know where my mind went... sorry, we had patch releases in 1.x :-)
On Fri, Feb 22, 2008 at 9:42 AM, Paul Benedict [EMAIL PROTECTED] wrote:
I propose this:
Major point releases (1.0, 2.0, 3.0) is where Committers:
* May add API signatures
* May modify API signatures
* May
@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
@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
, February 22, 2008 2:54 PM
Subject: Re: API Compatibility
Al Sutton wrote:
Just so we're all on the same page, can I put forward the following as a
version numbering plan which would seem to reflect most peoples views;
2.0.x - New releases shouldn't alter the public API unless absolutley
to imply API
freeze and compatibility. Innovation and API compatibility are not
mutually exclusive. Folks just have to understand what they can and
cannot do to APIs. For example, you cannot remove any methods or classes
otherwise, it isn't compatible. You can add new methods and classes
of project goal or
philosophy -
which needs to be enforced by defining commonly accepted rules.
I agree for the most part, but also use version numbers to imply API
freeze and compatibility. Innovation and API compatibility are not
mutually exclusive. Folks just have
Don Brown wrote:
But don't you see, if we used the more traditional 1.0-alpha-1 -
1.0-beta-1 - 1.0-rc-1 - 1.0 then we could produce releases that
drastically changed the API within a single version. As it is now,
there could very well be huge changes from 1.0 to 1.0.1 because every
release gets
On 2/22/08, Brian Pontarelli [EMAIL PROTECTED] wrote:
Here's an example... The XWork configuration API changed to the builder
pattern. This is probably a good thing, but required any plugin using it
to make significant changes and re-compile. This change wasn't
compatible and there are
Don Brown wrote:
On 2/22/08, Brian Pontarelli [EMAIL PROTECTED] wrote:
Here's an example... The XWork configuration API changed to the builder
pattern. This is probably a good thing, but required any plugin using it
to make significant changes and re-compile. This change wasn't
I do not agree that classes that are public belong to the public API. It's
rather well-known that when complex subpackage structures are created, there
is no other way to share classes except to make them public. That is why,
imo, the javadocs be produced in 2: one API that is officially
On 2/22/08, Paul Benedict [EMAIL PROTECTED] wrote:
I would strongly suggest that Struts 2.1 refactor itself, if necessary, to
separate out the public and internal API and produce two distrinct javadocs
and source bundles based on these. Since 2.1 is already incompatible for
plugins, I
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
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
Don Brown wrote:
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
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
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
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
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
Jeromy Evans wrote:
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
On Thu, Feb 21, 2008 at 7:03 PM, Brian Pontarelli [EMAIL PROTECTED]
wrote:
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
I think it will benefit everyone to read this three part piece on evolving
APIs:
http://wiki.eclipse.org/index.php/Evolving_Java-based_APIs
Paul
On Thu, Feb 21, 2008 at 10:37 PM, Martin Cooper [EMAIL PROTECTED] wrote:
On Thu, Feb 21, 2008 at 7:03 PM, Brian Pontarelli [EMAIL PROTECTED]
wrote:
Just so we're all on the same page, can I put forward the following as a
version numbering plan which would seem to reflect most peoples views;
2.0.x - New releases shouldn't alter the public API unless absolutley
neccessary (e.g. something is a security risk).
2.1.x (pre-first GA) - Changes
innovation at that point.
For me, API stability needs to be some kind of project goal or philosophy -
which needs to be enforced by defining commonly accepted rules.
I agree for the most part, but also use version numbers to imply API
freeze and compatibility. Innovation and API compatibility
or philosophy -
which needs to be enforced by defining commonly accepted rules.
I agree for the most part, but also use version numbers to imply API
freeze and compatibility. Innovation and API compatibility are not
mutually exclusive. Folks just have to understand what they can and
cannot do
39 matches
Mail list logo
