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
2008/2/22, Martin Cooper [EMAIL PROTECTED]:
On Thu, Feb 21, 2008 at 8:24 AM, Antonio Petrelli
[EMAIL PROTECTED] wrote:
What about the XAP framework then:
http://incubator.apache.org/xap/
At least that team have already scratched their head :-)
Well, understand that XAP is still in the
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 the same and, in
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*
Good idea!
On Fri, Feb 22, 2008 at 2:23 AM, Vinod Kumar Kashyap (JIRA)
[EMAIL PROTECTED] wrote:
JCaptcha
Key: WW-2502
URL: https://issues.apache.org/struts/browse/WW-2502
Project: Struts 2
Issue Type: New Feature
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
Hi guys,
I'm just a Struts 2 (heavy) user, but I think I can contribute with that.
Sometime ago I wrote a Struts Interceptor and a Sitemesh Decorator Mapper
that can apply a different (sometimes empty) decorator when you have an ajax
request:
mapper
Try ExtJS and u will find it amazing.
jmitchell wrote:
I think everyone should take a long serious look at ExtJS. I'm using
it on my current gig right now (very large s2 app) and except for a
few small quirks, it is helping us cover far more ground than we could
without it or with a
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
It sounds good, but my question would be; what happens if a plugin is deemed
good enough to include in the core?, would this count as an API addition and
therefore justify a 2.2?
Al.
- Original Message -
From: Paul Benedict [EMAIL PROTECTED]
To: Struts Developers List
It sounds good, but my question would be; what happens if a plugin is deemed
good enough to include in the core?, would this count as an API addition and
therefore justify a 2.2?
Al.
- Original Message -
From: Paul Benedict [EMAIL PROTECTED]
To: Struts Developers List
The problem with the method you mention is that with the apache release
voting system we don't know the quality of the release until after it's been
made and voted on, so we can't release an alpha version because until the
vote has happened it may turn out to be a full release.
I also believe
Do we only use apache for core plugins?
I'm thinking of creating a plugin to use JCaptcha, and I've never setup
a googlecode project. I was just wondering if we're trying to keep the
list of plugins in SVN small...
(On a side note, anyone want to help?)
-Wes
On Fri, Feb 22, 2008 at 6:44 PM, Wes Wannemacher [EMAIL PROTECTED] wrote:
Do we only use apache for core plugins?
We're not limited to only Apache License, but there are limitations on what
we can use, and there are ongoing discussions on a policy for that. Given
that JCaptcha is LGPL, though,
On Fri, 2008-02-22 at 19:01 -0800, Martin Cooper wrote:
On Fri, Feb 22, 2008 at 6:44 PM, Wes Wannemacher [EMAIL PROTECTED] wrote:
Do we only use apache for core plugins?
We're not limited to only Apache License, but there are limitations on what
we can use, and there are ongoing
23 matches
Mail list logo
