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 ongoi
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, thoug
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
-
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. Numbers are bumped based on a
finished
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"
Sent: Fr
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"
Sent: Fr
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 believ
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
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 d
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:
I use it to graceful
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
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
>
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
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 m
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
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
24 matches
Mail list logo
