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 g
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
y 22, 2008 8: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
justify a 2.2?
>
> Al.
>
> - Original Message -
> From: "Paul Benedict" <[EMAIL PROTECTED]>
> To: "Struts Developers List"
> Sent: Friday, February 22, 2008 3:42 PM
> Subject: Re: API Compatibility
>
>
> >I propose this:
> >
> > Major
evelopers List"
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 wh
evelopers List"
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 wh
"Struts Developers List"
Sent: Friday, 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
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
> * M
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 A
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 t
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 to
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
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-friendl
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 (pre-fi
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 ob
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
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
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
AIL PROTECTED]>
To: "Struts Developers List"
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"
t
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 depr
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
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]>
> w
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 rele
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 revi
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
uniqu
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
disapp
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'
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 sai
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 possi
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 necessari
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.
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
oth
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 b
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 supportabl
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
compati
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 a
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 ge
few other things that will severely break plugins
> and
> >> >> applications. After that release, API changes should be compatible so
> >> >> that plugins and applications can be upgraded without requiring
> >> >> re-compiling.
> >> >>
&
This would imply stopping 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 compat
roject milestone. This would imply stopping 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 al
ome feature
set or project milestone. This would imply stopping 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
42 matches
Mail list logo
