that uses ants 'propertyFile' task to automatically increment a build number.
This build number is stored in the ant generated manifest file of the built jar/war file.
For the first 'versioned' build, ant either copies the version.properties.sample file
to version.properties or creates a version.properties file from scratch if the sample doesn't exist.
A base build number is specified such as 1.3.0 to that a forth build number is added
so the first build is 1.3.0.1, second 1.3.0.2 etc...
Since Craig does the nightly builds there would be little danger say multiple 1.3.0.23 floating around
that were built at different dates, especially since the manefest file has the name of the person who built it also.
It would take very little to add this to the current build process.
-Rob
Martin Cooper wrote:
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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
