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]