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]
