I hate to bring this question back, but do we have a final decision on
how 1.x and 2.x codebases are treated name-wise and what is the
official way to refer to a product/version?

Because seems that Don, for example, have a different idea on naming:

"I think it is as simple as Struts 1.3, Struts 1.4, Struts 2.0, Struts 2.1,
etc...  The whole point of this proposal is to unify Struts as a single project,
getting away from this concept of separately versioned "subprojects".  There
will be Struts 1.x releases, and there will be Struts 2.x releases, and perhaps
some day, Struts 3.x releases."

I would prefer having Struts 1 and Struts 2 *names* as you stated, but
to Don and some others these are just different *versions of one
product* , and apparently should be written as Struts 1.x or Struts
2.x

[ Approach 1: generations/branches ]

* Struts 1.x, 2.x and any consecutive codebases is collectively called
Struts Framework  (full name) or just Struts (short name). BTW, Have
we decided to drop "Action" or the full official name is Struts Action
Framework?
* Struts 1.x codebase is collectively called Struts 1 where "1" is
part of the name.
* Struts 2.x codebase and any concecutive codebases is collectively
called Struts 2; "2" is part of the name.

[ Approach 2: one unified product]

* Struts 1.x, 2.x and any concecutive codebases is collectively called
Struts Framework  (full name) or just Struts (short name).
* Struts 1.x codebase is collectively called Struts 1.x where "1.x"
designates version range.
* Struts 2.x codebase is collectively called Struts 2.x where "2.x"
designates version range.
* Same pattern goes for future codebases. Therefore there are no
official "Struts 1" or "Struts 2" names/products.

Few people see what happens in SVN. But documentation is highly
visible, and we must choose one approach and follow it strictly. I
prefer the first one because it assumes that 1.x codebase is not
immediately replaced with 2.x codebase and still can be developed
separately (yes, this is marketing stuff). Anyway, I will obey any
decision, we just need to make *one*. Have I missed it? After the
final naming decision is made, proper names MUST be used in Javadocs,
site docs, public emails and in other places.

[ Code Names ]

Codenames like "Classic" for 1.x codebase is a separate issue and this
too must be finally dicided on. We discussed it many times, but have
the official and final decision been made? We need to chose official
(while optional) names and use only them or not use any codenames at
all.

Michael.

On 7/2/06, Niall Pemberton <[EMAIL PROTECTED]> wrote:
It might appear redundant but "Struts 1" is the name rather than
version number and hopefully what people will get used to distinguish
between the two flavours on offer. Its no different than what Sun did
when they introduced Java 2 and who knows where out version numbers
are going to go in the two parts.  That in itself is good enouh reason
to leave it IMO - but also I'm against overriding the defaults of the
build unless absolutely necessary - that way if things change in the
future theres less places to remember. If we'd done this in the
previous year we would have had to correct it 3 or 4 times!

Niall


On 7/2/06, Paul Benedict <[EMAIL PROTECTED]> wrote:
> Wendy, thanks. I understand the proposal. Version 1 is already in 1.3.5; so 
it doesn't need to be said everytime; the version number is enough to indicate its 
version 1.
>
> Wendy Smoak <[EMAIL PROTECTED]> wrote: On 7/2/06, Paul Benedict
>  wrote:
>
> > Does anyone else find this kind of title redudant?
> > Struts 1 - Core 1.3.5-SNAPSHOT API
> > We can specify it in the pom. I recommend:
> > Struts Core 1.3.5-SNAPSHOT API
>
> This change results from Don's proposal thread [1] about renaming
> Struts Action -> Struts, in which I believe the consensus was to go
> with 'Struts 1' and 'Struts 2'.
>
> [1] 
http://www.nabble.com/-PROPOSAL--Rename-Struts-Action-as-Struts-tf1864462.html
>
> --
> Wendy

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to