I would suggest the following:
* While in development, we continue to use the "-dev" suffix on the
version number, with the version number itself being the next
anticipated build.
* Starting now, all subprojects use 1.3.0-dev as their version number.
This is probably the only time they'll ever be in sync, but I think we
should all start on the same page.
* Subprojects increase their version numbers as needed, with no need
to sync up with any other subproject's version number.
As for bundles, I'm not totally convinced that we need them,
especially as more people move to Maven. If we do decide to provide
them, then I also don't have any good ideas for versioning them, or
even how to define them, in terms of subprojects and when we would
create a new one. (Would we create a new one each time any subproject
has a new release? That would be a pain, and probably annoying /
confusing to users. But if not, what would be the criteria for a new
bundle?)
As you mentioned, Joe, the J2EE numbering doesn't really tell you very
much. It makes for interesting Cactus versioning, too, since Cactus
embeds both its version number and the J2EE version number in its
distro names. Yuk.
I'd say let's forget about bundles, at least for the time being, and
simply focus on getting the various subprojects sorted out and
released in their new incarnations. Then we can see what the uptake
is, and what the community thinks with respect to keeping things
separate or defining some kind of bundling scheme.
--
Martin Cooper
On Wed, 19 Jan 2005 12:17:44 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote:
This raises a question which I don't feel we've really pinned down
yet -- how should we version artifacts between releases? Right now,
the result of maven jar for struts-el is "struts-el-1.2.6.jar", which
is misleading.
This is independent of another question, which we should also
probably discuss, which is how we version non-core artifacts. I
generally prefer sharing version numbers -- I find the J2EE
methodology of rolling in a number of disparate version numbers into
a single release continually confusing, although I think that Ted has
suggested it as the approach for future Struts releases once we have
our pieces all broken out. I know that if we want things to have
their own release cycle, then we may not simply be able to share the
major "Struts version number", but like I said, I'm not real fond of
the only other alternative I have thought of.
I admit to having no solid proposal for either of these things.
For between-release artifacts, I have seen someone use "SNAPSHOT" in
a version name, which I would recommend against, as Maven always
tries to download dependencies which contain that string, something
which quickly becomes tiresome. I would prefer that we not use real
version numbers in the project.xml file until the moment when a
release is being cut, to avoid confusion.
In my uncommitted work on the ActionContext, I am using
"struts-1.3.0-dev". I think using the expected next release number
plus "-dev" is a decent compromise, but I'm happy to hear other ideas.
Joe
At 5:46 PM +0000 1/19/05, [EMAIL PROTECTED] wrote:
Author: jmitchell
Date: Wed Jan 19 09:46:35 2005
New Revision: 125632
URL: http://svn.apache.org/viewcvs?view=rev&rev=125632
Log:
el now builds a good distribution (well, with maven anyway)
Modified:
struts/el/trunk/project.xml
--
Joe Germuska
[EMAIL PROTECTED]
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
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]
