On Wed, 19 Jan 2005 22:12:45 -0500, Robert Leland <[EMAIL PROTECTED]> wrote: > For the in between official releases for our project at work I created a > 'all-versioned' target > 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...
We do this kind of thing on my day-job projects as well ... but it only works when there is one authoritative source of builds that have "real" version numbers. (For Creator, we have a Release Engineering group that does just this kind of thing, and nobody else can generate an "official" build.) What happens when some random downloader of the source code generates a build and happens to make it available to other folks? Result is a second (or third, or ...) instance of the same build number, and confusion in the world over which one is official. No, change "random downloader" to "Gump" (which also publishes its artifacts, at least for a short amount of time) and see what happens ... > > 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. > You could say that about nightly builds ... I don't see how you deal with builds from other sources. In the mean time, I like Martin's suggestion of a "-dev" suffix, which is a practice at least some of the commons packages follow already. > -Rob Craig > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
