I haven't been a fan of the naming convention being introduced, and I've said so in the past. But, as Ted points out in another post, no one, including me, offered any better suggestions either, so it was just pointless whining. Let me try and change to something more constructive...
Why not take a cue from Microsoft (G-d forbid!) as well as countless other companies? There is Windows. Then there is Windows Workstation. Then there is Windows Server. And so on. There is Ford. Then there is a Ford Taurus. Then there is a Ford Windstar. And so on. Point: you have a basic brand name with some tacked on word that describes a brand extension, or sub-type. There should, IMO, always be something called Struts because it has market awareness and there's no point in willingly giving that up. What should that something be? I would say at this point that the project itseld should be called Struts, kind of a meta term to describe everything (more akin to Ford than Windows in that case). I don't think anyone has suggested not doing this, but wanted to state it anyway. The one convenience download that includes all the subcomponents should also simply be called Struts. Why confuse people who already have an understand of what Struts is? >From that point on, you have all the sub-projects being named Struts XXXX... unless they are actually moved out of Struts, then they should be subprojects not of Struts but of Jakarta or Apache, and I think this is what should be happening... should Validator be Struts Validator? No, it should be Apache Validator, or something like that, because it isn't tied to Struts any more. Likewise, when you have the version that integrates JSF, you call it Struts JSF. You might also get Struts Shale, and of course Struts Ti, etc. This indicates to people that this is clearly a subproject of the larger Struts project they already know about, perhaps the next evolution of Struts even. I agree with the sentiment that Struts Classic is not the best choice. It carries certain connotations that one would hope are not trying to be conveyed. I think it also just confuses matters because until there is something that supplants the current Struts in a linear fashion, it doesn't make sense... I mean, Microsoft isn't going to go name Windows XP with service pack 3 Windows Classic. They might be able to get away with that when Vista is release though (arguably at least). So, when Struts 2.0 is ready, in whatever form that takes, and it is obvious that it's a big enough change that it warrants being 2.0, then calling the 1.x line Classic makes sense. I don't believe that is the case going from 1.2.7 to 1.3. As Ted pointed out, it's arguable whether 1.3 is revolutionary or evolutionary (I'd vote for the later, but a very good evolution). So, in short: Struts | =---- Struts Core * | =---- Struts Taglibs * | =---- Struts Shale | =---- Struts Ti Some other top-level thing, maybe Apache? | =---- Tiles * | =---- Validator * * These all combined are simply called Struts, so that when someone goes to download Struts, that's what they get, unless they choose to download the individual subcomponents separately. Frank On Tue, November 1, 2005 8:07 am, Ted Husted said: > On 11/1/05, Wolfgang Gehner <[EMAIL PROTECTED]> wrote: >> So let me formally propose that Struts point releases as of 1.3 >> including be called Struts CORE. > > I think the point that people are missing is that Struts Classic is > not a product, it's a distribution of products. Struts Core is one > product, Struts Taglibs is another. Each has it's own release cycle > and can be distributed separately. > > As a convenience, we plan to bundle the GA releases for the six > original subprojects into a single distribution, for downloading > convenience. > > :) Which begs another moniker. Instead of Struts Classic, we could > also call the distribution Struts Original. :) > > As it stands, we don't want there to be one Struts, since one Struts > can't serve everyone's needs right now. Some of us want to rewrite our > applications for new technologies like JSF. Others want to continue to > evolve the applications we already have and avoid drastic change. > Since we have volunteers who want to do both, we do both. > > Sure, if this was about capturing marketshare, we'd pick a horse and > label it Struts 2.x. But it's not about marketshare, it's about > working together to create and maintain the framework we want to use > to ship our own applications. Since no one's come up with a way to > create one framework that will serve everyone's needs right now, the > only option left is multiple frameworks. > > -Ted. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
