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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
