You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Wendy Smoak <ws...@gmail.com> on 2005/11/03 03:44:02 UTC
Struts Core Library versioning (was: Re: [Struts Wiki] Update of "StrutsClassicRelease130" by TedHusted)
> The following page has been changed by TedHusted:
> http://wiki.apache.org/struts/StrutsClassicRelease130
>
> The comment on the change is:
> Per discussions on dev@, phase in the "Struts Core Library" idea.
>
> - * Download the Struts 1.3.0 distribution from http://svn.apache.org/dist/struts/classic/v1.3.0/
> + * Download the Struts Core Library distribution from http://svn.apache.org/dist/struts/core-library/v1.0.0/
I like the new name, but have reservations about starting with version 1.0.0.
I know this is the first ever "Struts Core Library", but to most
people it's just Struts, and Struts already had a 1.0 release.
Yes, it's a marketing thing. :) How about Struts Core Library 1.3.0 ?
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts Core Library versioning
Posted by Ted Husted <te...@gmail.com>.
On 11/3/05, Greg Reddin <gr...@apache.org> wrote:
> One queston: Will we ever release the distro again? Or will each
> subproject just release independently?
Right now, I'm thinking that there will be an initial "test"
distribution when the original seven dwarfs are ready for wider
testing. After that, each could be released independantly as changes
were made.
Once the original seven are all marked "General Availability", we
could roll the first GA release of the Struts Core Lbirary
distribution. If other subproejcts that utilize Struts Core are also
GA, then they coudl be included too.
As each Struts Core extension has a new GA release, we would update
the Struts Core Library distribution,so that it always has the current
set of GA releases for the target products.
Of course, a requirement for getting a GA stamp would be that it works
with the other GA releases, so it is a foregone conclusion that the
target products would continue to work together.
> It seems like all the stars will have to line up in a unique way
> for there to ever be a coordinated distro release after the first one.
This is the state of affairs with the Struts 1.2.x and prior series,
and one reason the project is moving so slowly. We created the
subprojects so that someone could work on one, and release it,
without having to be compatible with the unreleased development code
in other areas. Now, we would just have to worry whether a subproject
release is compatible with the other GA releases, not with what we
have cooking.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts Core Library versioning
Posted by Wolfgang Gehner <ne...@infonoia.com>.
How Eclipse recommends their plugin versions, for RCP apps: a distro
such as 3.1 "can" have modules (plugins) that have different versions,
but the recommended way is to push the distro version to the plugins, so
whatever plugins were 3.1.4 or whatever become 3.2.0 in the next distro.
People understand that there are not necessarily new features, but I
guess it signifies that the 3.2.0 suite was tested together, which is
nice to know. Of course 3rd party plugins (not spearheaded by eclipse)
are completely free to use their own version cycle, such as
org.junit_3.8.1; for example the ant plugin to eclipse 3.1 is
org.apache.ant_1.6.5.
Wolfgang
Greg Reddin wrote:
> I guess I long for simplicity. I'm cool with the way everything is
> structured. I would prefer a version number on the distro. And to
> me it seems more natural to start it with 1.3.0. That's what we're
> doing with the Tiles subproject. Even though it's really release 0.1
> of the Tiles subproject itself, we just called it 1.3.0 to be done
> with it and not have to answer the "Where's Tiles 1.3?" questions.
>
> I think people will be confused if they download struts-core-
> library-1.0.0. And I think struts-core-library-20051103 will convey
> the idea that it's not really "done" yet. But that's my opinion and
> it's not really a big deal to me.
>
> One queston: Will we ever release the distro again? Or will each
> subproject just release independently? It seems like all the stars
> will have to line up in a unique way for there to ever be a
> coordinated distro release after the first one. So maybe the distro
> doesn't need a version number or a date stamp. Maybe it's just a zip
> file that people download that gets the latest release of all the
> subprojects.
>
> Greg
>
>> Ted Husted wrote:
>>
>>> On 11/2/05, Frank W. Zammetti <fz...@omnytex.com> wrote:
>>>
>>>> Why wouldn't there simply be a distro called Struts that includes
>>>> Core
>>>> (which happens to map to the core subproject) and the original seven
>>>> subprojects, plus the three new ones if you want?
>>>>
>>> There is. But, it is not named "Struts" because Struts is now the name
>>> of the project, and the project also includes Struts Shale.
>>>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts Core Library versioning
Posted by Greg Reddin <gr...@apache.org>.
I guess I long for simplicity. I'm cool with the way everything is
structured. I would prefer a version number on the distro. And to
me it seems more natural to start it with 1.3.0. That's what we're
doing with the Tiles subproject. Even though it's really release 0.1
of the Tiles subproject itself, we just called it 1.3.0 to be done
with it and not have to answer the "Where's Tiles 1.3?" questions.
I think people will be confused if they download struts-core-
library-1.0.0. And I think struts-core-library-20051103 will convey
the idea that it's not really "done" yet. But that's my opinion and
it's not really a big deal to me.
One queston: Will we ever release the distro again? Or will each
subproject just release independently? It seems like all the stars
will have to line up in a unique way for there to ever be a
coordinated distro release after the first one. So maybe the distro
doesn't need a version number or a date stamp. Maybe it's just a zip
file that people download that gets the latest release of all the
subprojects.
Greg
> Ted Husted wrote:
>
>> On 11/2/05, Frank W. Zammetti <fz...@omnytex.com> wrote:
>>
>>> Why wouldn't there simply be a distro called Struts that includes
>>> Core
>>> (which happens to map to the core subproject) and the original seven
>>> subprojects, plus the three new ones if you want?
>>>
>> There is. But, it is not named "Struts" because Struts is now the
>> name
>> of the project, and the project also includes Struts Shale.
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts Core Library versioning
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Ted Husted wrote:
> As Martin has already explained, there is an experimental area called
> the Sandbox, and that's where Ti lives now. Shale has already been
> there and done that. Shale is not an experiment. Shale is a
> first-class citizen of the Apache Struts project. Get used to it.
Yes, I understand the sandbox concept.
None of my comments were meant as a swipe on Shale by the way... if any
of it was taken that way, they were misread.
I am probably not expressing my concern well, in which case I can't hope
to convince anyone. I've had my say though, and that's all I can do
anyway. Thanks for listening.
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts Core Library versioning
Posted by Ted Husted <te...@gmail.com>.
On 11/2/05, Frank W. Zammetti <fz...@omnytex.com> wrote:
> If there was an "experimentation" group, or a "Future Struts Proposals",
> or something along those lines, which could include Ti and others as
> well, then I believe that more accurately describes how these things
> relate to each other.
As Martin has already explained, there is an experimental area called
the Sandbox, and that's where Ti lives now. Shale has already been
there and done that. Shale is not an experiment. Shale is a
first-class citizen of the Apache Struts project. Get used to it.
Struts developers who would like to use JSF are invited to consider
Shale for their project. Other Struts developers are invited to
continue using Struts Core and friends.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts Core Library versioning
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Ted Husted wrote:
> On 11/2/05, Frank W. Zammetti <fz...@omnytex.com> wrote:
>
>>Why wouldn't there simply be a distro called Struts that includes Core
>>(which happens to map to the core subproject) and the original seven
>>subprojects, plus the three new ones if you want?
>
>
> There is. But, it is not named "Struts" because Struts is now the name
> of the project, and the project also includes Struts Shale.
I was afraid you were going to say that :)
I don't want to get into an argument here, and I very much doubt I'm
going to change anyones' mind at this juncture, so I'll just make this
point and leave it at that... I think Shale's status in the Struts
project is where the confusion really comes from.
Well, I have to be fair... it's where the confusion *that I believe will
ensue* comes from. It's not like I've had to explain to anyone how
things are lately, but I believe that's what will start to happen.
If Shale is to become it's own project under Apache, then there's no
issue, this is just an interm problem. If that's not the goal though,
and I never thought it was, then this is where my suggestion yesterday
about an "experimentation" grouping came in... If it's to remain
related to Struts, and as it is now billed as a "proposal for a
next-generation Struts" then it should be, why should it be displayed on
the site at the same level as the Core framework? I don't believe it
should be on the same footing, or else it should be its own project.
If there was an "experimentation" group, or a "Future Struts Proposals",
or something along those lines, which could include Ti and others as
well, then I believe that more accurately describes how these things
relate to each other.
Then, when people go and want to download "Struts", they get what we
might think of as "Struts Classic" (I could slap myself for saying
that!). Struts remains a tangible thing, not just a project name, which
jives with what people now understand Struts to be. If they want Shale,
they know it's really something different that just HAPPENS to be a
possible next evolution of Struts, and they also understand that it's
truly a subproject of the larger Struts project, which I don't think is
clear right now. It isn't to me at least (and it could certainly just
be me, I'm willing to entertain that possibility!)
> We could include Shale in the same distribution, but I don't think
> that makes as much sense as a distribution of the products that
> utilize the original Struts Core.
Agreed there, regardless of anything I said above. Definitely should a
completely different download.
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts Core Library versioning
Posted by Craig McClanahan <cr...@apache.org>.
On 11/2/05, Ted Husted <te...@gmail.com> wrote:
>
> It's not uncommon for branded products to use dates as an identifier.
> Microsoft does it all the time. Of course, whether they actually test
> those products, I won't venture to say. :)
Sun has tried that branding approach as well on occastion (including the
previous version of the product I'm responsible for ... "Sun Java Studio
Creator 2004Q2" was *not* my idea :-). But it also doesn't meet user
expectations around version numbers -- chiefly the (somewhat theoretical :-)
distinction between major and minor updates. Thankfully, our next version
will be "Sun Java Studio Creator 2.0".
And, I seem to recall Microsoft getting razzed pretty loudly when they
almost missed the calendar for Windows 98 and Windows 2000 releases that
were very nearly in the following year ...
Craig
On 11/2/05, Craig McClanahan <cr...@apache.org> wrote:
> > *That* is the characteristic that a nightly build type conglomeration of
> > parts does not have, and why such a tested combination needs to be
> branded
> > as something different than just "here's the set of parts that I pulled
> > together on such-and-such a date".
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: Struts Core Library versioning
Posted by Ted Husted <te...@gmail.com>.
It's not uncommon for branded products to use dates as an identifier.
Microsoft does it all the time. Of course, whether they actually test
those products, I won't venture to say. :)
On 11/2/05, Craig McClanahan <cr...@apache.org> wrote:
> *That* is the characteristic that a nightly build type conglomeration of
> parts does not have, and why such a tested combination needs to be branded
> as something different than just "here's the set of parts that I pulled
> together on such-and-such a date".
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts Core Library versioning
Posted by Craig McClanahan <cr...@apache.org>.
On 11/2/05, Ted Husted <te...@gmail.com> wrote:
>
> On 11/2/05, Frank W. Zammetti <fz...@omnytex.com> wrote:
> > Why wouldn't there simply be a distro called Struts that includes Core
> > (which happens to map to the core subproject) and the original seven
> > subprojects, plus the three new ones if you want?
>
> There is. But, it is not named "Struts" because Struts is now the name
> of the project, and the project also includes Struts Shale.
>
> We could include Shale in the same distribution, but I don't think
> that makes as much sense as a distribution of the products that
> utilize the original Struts Core.
>
> In the pre-Maven days, we had a Struts Library distribution that
> contained all the JARs. Using the name "Struts-Core-Library" for this
> distribution harkens back to that.
Whatever we decide to call the combination release, it deserves a version
number of its own, independent of its constituent parts. Think of your
favorite Linux distribution (Debian, SUSE, Red Hat, whatever) ... it is
released with a particular version number, and consists of particular
versions of its parts, which have (in theory at least) all been tested for
interoperability and compatibility at a particular point in time.
*That* is the characteristic that a nightly build type conglomeration of
parts does not have, and why such a tested combination needs to be branded
as something different than just "here's the set of parts that I pulled
together on such-and-such a date".
Craig
-Ted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: Struts Core Library versioning
Posted by Ted Husted <te...@gmail.com>.
On 11/2/05, Frank W. Zammetti <fz...@omnytex.com> wrote:
> Why wouldn't there simply be a distro called Struts that includes Core
> (which happens to map to the core subproject) and the original seven
> subprojects, plus the three new ones if you want?
There is. But, it is not named "Struts" because Struts is now the name
of the project, and the project also includes Struts Shale.
We could include Shale in the same distribution, but I don't think
that makes as much sense as a distribution of the products that
utilize the original Struts Core.
In the pre-Maven days, we had a Struts Library distribution that
contained all the JARs. Using the name "Struts-Core-Library" for this
distribution harkens back to that.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts Core Library versioning
Posted by Michael Jouravlev <jm...@gmail.com>.
Whether "classic" has a bad flair or not, it is much closer to real
state of things, than Struts Core, which is not actually a core. Using
a fancier name (from the point of view of some marketing-affected
people) instead of cleaner and true name does not make much sense to
me. Neither as 2 calories' green salad with thick cheesy dressing and
oily breadsticks.
On 11/2/05, Frank W. Zammetti <fz...@omnytex.com> wrote:
> I for one would have no objection to dating. That's a good compromise.
> I still think a version number would be better, but a date I could
> certainly live with.
>
> The naming I still would contend is confusing though.
>
> Why wouldn't there simply be a distro called Struts that includes Core
> (which happens to map to the core subproject) and the original seven
> subprojects, plus the three new ones if you want? That to me makes a
> lot more sense. I would even argue that the new three should NOT be
> part of the distro and should instead remain extensions, but I'm less
> concerned with that than what I think is a bit of a confusing name.
>
> Come on, we got rid of Classic, a move I definitely agree with, let's go
> this next step :-)
>
> Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts Core Library versioning
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
I for one would have no objection to dating. That's a good compromise.
I still think a version number would be better, but a date I could
certainly live with.
The naming I still would contend is confusing though.
Why wouldn't there simply be a distro called Struts that includes Core
(which happens to map to the core subproject) and the original seven
subprojects, plus the three new ones if you want? That to me makes a
lot more sense. I would even argue that the new three should NOT be
part of the distro and should instead remain extensions, but I'm less
concerned with that than what I think is a bit of a confusing name.
Come on, we got rid of Classic, a move I definitely agree with, let's go
this next step :-)
Frank
Ted Husted wrote:
> On 11/2/05, Frank W. Zammetti <fz...@omnytex.com> wrote:
>
>>I expected to see a Struts distro that combined core and flow and
>>scripting and whatever else that when combined formed what we know now
>>as Struts. Anything else would be an extension.
>
>
> By a distribution I mean that we zip up subprojects that people will
> probably want to use together into a single download. In the case of
> ah "Struts-Core-Library" distribution, this would be Struts Core and
> all the extension that are compatible with Struts Core. Right now,
> that would be the original seven subprojects, plus Scripting, Flow,
> and Faces.
>
> At this point, I agree that using version numbers with a distribution
> like that would be confusing, and it might be better to just date
> them, like the nightly build.
>
> -Ted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
> .
>
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: fzammetti@hotmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts Core Library versioning
Posted by Ted Husted <te...@gmail.com>.
On 11/2/05, Frank W. Zammetti <fz...@omnytex.com> wrote:
> I expected to see a Struts distro that combined core and flow and
> scripting and whatever else that when combined formed what we know now
> as Struts. Anything else would be an extension.
By a distribution I mean that we zip up subprojects that people will
probably want to use together into a single download. In the case of
ah "Struts-Core-Library" distribution, this would be Struts Core and
all the extension that are compatible with Struts Core. Right now,
that would be the original seven subprojects, plus Scripting, Flow,
and Faces.
At this point, I agree that using version numbers with a distribution
like that would be confusing, and it might be better to just date
them, like the nightly build.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts Core Library versioning
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
I find this to be even more confusing on two counts...
First, the version numbers, I thought the idea was that subprojects
could develop independently of one another... in that case, it doesn't
really matter if they all start at 1.0.0 or not.
Second, I know we discussed this yesterday, but I DIDN'T understand
struts-core to be the all-encompassing distruction... I understood it to
essentially be one component of that distro, the one representing the,
well, CORE functionality of Struts.
I expected to see a Struts distro that combined core and flow and
scripting and whatever else that when combined formed what we know now
as Struts. Anything else would be an extension.
But just as far as the version numbers ago, I'm completely +1 with what
Wendy said... it will only serve to confuse people if the version
numbers seemingly "revert" now.
Frank
Ted Husted wrote:
> On 11/2/05, Wendy Smoak <ws...@gmail.com> wrote:
>
>>I like the new name, but have reservations about starting with version 1.0.0.
>>
>>I know this is the first ever "Struts Core Library", but to most
>>people it's just Struts, and Struts already had a 1.0 release.
>>
>>Yes, it's a marketing thing. :) How about Struts Core Library 1.3.0 ?
>
>
> I started to do that, but the idea was to also include the new
> subprojects, like Scripting and Flow and Faces, which would start at a
> 1.0.0 release. It seemed consistant to start with 1.0.0.
>
> And, it's *VERY* important that people realize that Struts Core
> LIbrary is *not* a product, it's a distribution of products, like a
> Linux distribution. That was already becoming a problem with the
> Struts Classic moniker.
>
> Perhaps we don't want to number the disitributions. Maybe we should
> just date them, like a nighly build.
>
> * struts-core-library-20051102.zip
>
> -Ted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
> .
>
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: fzammetti@hotmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts Core Library versioning (was: Re: [Struts Wiki] Update of "StrutsClassicRelease130" by TedHusted)
Posted by Michael Jouravlev <jm...@gmail.com>.
On 11/2/05, Ted Husted <te...@gmail.com> wrote:
> On 11/2/05, Wendy Smoak <ws...@gmail.com> wrote:
> > I like the new name, but have reservations about starting with version 1.0.0.
> >
> > I know this is the first ever "Struts Core Library", but to most
> > people it's just Struts, and Struts already had a 1.0 release.
> >
> > Yes, it's a marketing thing. :) How about Struts Core Library 1.3.0 ?
>
> I started to do that, but the idea was to also include the new
> subprojects, like Scripting and Flow and Faces, which would start at a
> 1.0.0 release. It seemed consistant to start with 1.0.0.
What if another subproject is included later? Is that possible?
> And, it's *VERY* important that people realize that Struts Core
> LIbrary is *not* a product, it's a distribution of products, like a
> Linux distribution. That was already becoming a problem with the
> Struts Classic moniker.
Wasn't the Core just the core stuff, without contributed projects? You
guys lost me again ;-))
> Perhaps we don't want to number the disitributions. Maybe we should
> just date them, like a nighly build.
>
> * struts-core-library-20051102.zip
No opinion.
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts Core Library versioning (was: Re: [Struts Wiki] Update of "StrutsClassicRelease130" by TedHusted)
Posted by Ted Husted <te...@gmail.com>.
On 11/2/05, Wendy Smoak <ws...@gmail.com> wrote:
> I like the new name, but have reservations about starting with version 1.0.0.
>
> I know this is the first ever "Struts Core Library", but to most
> people it's just Struts, and Struts already had a 1.0 release.
>
> Yes, it's a marketing thing. :) How about Struts Core Library 1.3.0 ?
I started to do that, but the idea was to also include the new
subprojects, like Scripting and Flow and Faces, which would start at a
1.0.0 release. It seemed consistant to start with 1.0.0.
And, it's *VERY* important that people realize that Struts Core
LIbrary is *not* a product, it's a distribution of products, like a
Linux distribution. That was already becoming a problem with the
Struts Classic moniker.
Perhaps we don't want to number the disitributions. Maybe we should
just date them, like a nighly build.
* struts-core-library-20051102.zip
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts Core Library versioning (was: Re: [Struts Wiki] Update
of "StrutsClassicRelease130" by TedHusted)
Posted by Joe Germuska <Jo...@Germuska.com>.
At 7:44 PM -0700 11/2/05, Wendy Smoak wrote:
> > The following page has been changed by TedHusted:
>> http://wiki.apache.org/struts/StrutsClassicRelease130
>>
>> The comment on the change is:
>> Per discussions on dev@, phase in the "Struts Core Library" idea.
>>
>> - * Download the Struts 1.3.0 distribution from
>>http://svn.apache.org/dist/struts/classic/v1.3.0/
>> + * Download the Struts Core Library distribution from
>>http://svn.apache.org/dist/struts/core-library/v1.0.0/
>
>I like the new name, but have reservations about starting with version 1.0.0.
>
>I know this is the first ever "Struts Core Library", but to most
>people it's just Struts, and Struts already had a 1.0 release.
>
>Yes, it's a marketing thing. :) How about Struts Core Library 1.3.0 ?
+1 to Wendy's suggestion; it's not nearly as bad as Sun's version
number tomfoolery!
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts Core Library versioning
Posted by Martin Cooper <ma...@apache.org>.
On 11/3/05, Hubert Rabago <hr...@gmail.com> wrote:
>
> "Struts Classic" keeps making me think "That's not the version I want
> -- I want Struts Modern".
>
> On 11/3/05, Michael Jouravlev <jm...@gmail.com> wrote:
> > VW was making Bug/Beetle for 50 years or so, it acquired Classic
> > status sometimes in 60-ies, before Golf/Rabbit was introduced ;-)
>
> Well, no one's calling today's VW Bug "Beetle Classic" (although I
> liked the year 2000 model nickname "Y2KBug"). "Beetle Classic" makes
> me think "Herbie". Same thing happens when I hear/read "Struts
> Classic". It makes me think "Struts 1.0".
>
>
> > P.S. I'd rather see some progress in cloth washer design, seems that
> > it froze in 50-ies.
>
> And from what you said earlier, it's what they now call "classic".
> Again supporting my opinion. Calling 1.3 Struts Classic means "it's
> the same old Struts", with the emphasis on "same old", implying that
> there's something else, another version out there that isn't "old" and
> "classic". Well, what we have now is "Struts Modern", with the new
> flexible CoR request processor, where you can use Commands instead of
> Actions. Really doesn't deserve to be called "Classic" IMO.
Struts Contemporary, anyone? ;-)
This thread (or pair of threads) just emphasises that naming is one of the
hardest parts of software development...
--
Martin Cooper
Hubert
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: Struts Core Library versioning
Posted by Hubert Rabago <hr...@gmail.com>.
"Struts Classic" keeps making me think "That's not the version I want
-- I want Struts Modern".
On 11/3/05, Michael Jouravlev <jm...@gmail.com> wrote:
> VW was making Bug/Beetle for 50 years or so, it acquired Classic
> status sometimes in 60-ies, before Golf/Rabbit was introduced ;-)
Well, no one's calling today's VW Bug "Beetle Classic" (although I
liked the year 2000 model nickname "Y2KBug"). "Beetle Classic" makes
me think "Herbie". Same thing happens when I hear/read "Struts
Classic". It makes me think "Struts 1.0".
> P.S. I'd rather see some progress in cloth washer design, seems that
> it froze in 50-ies.
And from what you said earlier, it's what they now call "classic".
Again supporting my opinion. Calling 1.3 Struts Classic means "it's
the same old Struts", with the emphasis on "same old", implying that
there's something else, another version out there that isn't "old" and
"classic". Well, what we have now is "Struts Modern", with the new
flexible CoR request processor, where you can use Commands instead of
Actions. Really doesn't deserve to be called "Classic" IMO.
Hubert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts Core Library versioning
Posted by Michael Jouravlev <jm...@gmail.com>.
On 11/3/05, Frank W. Zammetti <fz...@omnytex.com> wrote:
> Michael Jouravlev wrote:
> > I still don't get what is wrong with Struts Classic. Levi's 501 is
> > classic and looks much better than stupid baggy pants. Heinz Original
> > is better than some newer products. Can you reinvent ketchup? This can
> > be an idea for a slogan ;-)
>
> How can you have something that is "classic" until you have something
> that supercedes it? :)
VW was making Bug/Beetle for 50 years or so, it acquired Classic
status sometimes in 60-ies, before Golf/Rabbit was introduced ;-)
Of course, America has its own timeframe, where 3-year cycle is
considered eternity, and a car manufactured for two years in a row
without even minor restyling is considered dated. It does not matter
how well the car was thought out at the first place, new is always
better. Look, Ma, chrome strips and different wheel covers. Its a
f#$%ing new car now, baby!
> (P.S., they reinvented Ketchup 56 times, didn't they?!? LOL)
And why did they do that? See above.
P.S. I'd rather see some progress in cloth washer design, seems that
it froze in 50-ies.
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts Core Library versioning
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Michael Jouravlev wrote:
> I still don't get what is wrong with Struts Classic. Levi's 501 is
> classic and looks much better than stupid baggy pants. Heinz Original
> is better than some newer products. Can you reinvent ketchup? This can
> be an idea for a slogan ;-)
How can you have something that is "classic" until you have something
that supercedes it? :)
If Shale was to become Struts at some point for example, than what we
know today as Struts could be called Struts Classic and I think that
would be perfect.
But to tack on Classic today, without something newer to take its place,
doesn't make much sense, if for no other reason than semantics :)
> Michael.
Frank
(P.S., they reinvented Ketchup 56 times, didn't they?!? LOL)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts Core Library versioning (was: Re: [Struts Wiki] Update of "StrutsClassicRelease130" by TedHusted)
Posted by Michael Jouravlev <jm...@gmail.com>.
On 11/3/05, Laurie Harper <la...@holoweb.net> wrote:
> On the name, I agree with others that 'Struts Classic' gives the wrong
> impresion, but I'm not too keen on 'Struts Core Library'. That suggests
> that it's part of a larger set of libraries you need to download to use
> 'Struts' for those used to thinking in terms of Struts, the product as
> opposed to Struts, the project.
I still don't get what is wrong with Struts Classic. Levi's 501 is
classic and looks much better than stupid baggy pants. Heinz Original
is better than some newer products. Can you reinvent ketchup? This can
be an idea for a slogan ;-)
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts Core Library versioning (was: Re: [Struts Wiki] Update
of "StrutsClassicRelease130" by TedHusted)
Posted by Laurie Harper <la...@holoweb.net>.
Wendy Smoak wrote:
>>The following page has been changed by TedHusted:
>>http://wiki.apache.org/struts/StrutsClassicRelease130
>>
>>The comment on the change is:
>>Per discussions on dev@, phase in the "Struts Core Library" idea.
>>
>>- * Download the Struts 1.3.0 distribution from http://svn.apache.org/dist/struts/classic/v1.3.0/
>>+ * Download the Struts Core Library distribution from http://svn.apache.org/dist/struts/core-library/v1.0.0/
>
>
> I like the new name, but have reservations about starting with version 1.0.0.
>
> I know this is the first ever "Struts Core Library", but to most
> people it's just Struts, and Struts already had a 1.0 release.
>
> Yes, it's a marketing thing. :) How about Struts Core Library 1.3.0 ?
To add my 2 cents, I'm with Craig, Wendy and others on the versioning of
the bundle distribution: it needs a version number, and a proper version
number at that, not just a date stamp. I believe it should start at
1.3.0 as Wendy says, since there are a large number of people how
already are familiar with Struts the product, and the bundle release is
the continuation of that brand.
On the name, I agree with others that 'Struts Classic' gives the wrong
impresion, but I'm not too keen on 'Struts Core Library'. That suggests
that it's part of a larger set of libraries you need to download to use
'Struts' for those used to thinking in terms of Struts, the product as
opposed to Struts, the project. I think Struts Distribution is probably
the best suggestion I've seen for a product name to provide least
confusion to our users (as opposed to those of us who understand the
internal concerns arising from changing the way the project is organized
internally).
For component versioning, I prefer the idea of each subproject having a
version number with the same 'base' as the distribution it's initially
released in -- i.e. starting them at 1.3.0. But I have no real objection
to them having versions that are completely independant of the
distribution version; Struts and its sub-projects already have plenty of
dependencies on components whose versions are independant (i.e. the
external libraries from Commons and other sources).
The important goal here is to allow the subprojects to release new
versions outside the release cycle of the 'distribution' of the
product(s) that bundle them. From an external perspective, our users
want to be able to answer questions like
- what's the latest version of Struts (where we want to retrain them to
ask about the latest version of Struts Core Library or Struts Distribution)
- where do I download it?
- is Struts Subproject release X compatible with Struts release Y?
(where we want to retrain them to ask about compatibility with release Y
of Struts Distribution or whatever)
In other words, externally there still needs to be 'Struts, the product'
-- whatever name we decide to give that product to distinguish it from
the set of components it comprises. That product still needs to be
versioned and a first-class citizen within the Struts project that users
can talk about.
Compatability of versions of subprojects with the distribution product
can be guided by standard version numbering conventions, regardless of
what version numbers the subprojects start at. The issue of incrementing
the major number of a subproject's release version shouldn't affect this
much, since the distribution product should get a major number increment
as soon as it releases with that subproject release, anyway.
L.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org