Thanks for the information. I think I may need to clarify some things. > > Our applications are made up of a few dozen components, some of which > > are shared between projects and some of which are project-specific. > > Each of these components currently has a 4-component build number > > "major.minor.patch.build". When building a component, its build number > > is incremented. A new major, minor or patch version resets the build > > version to zero. I'm happy to change a dot to a hyphen, and I'd also > > be perfectly happy for that build number to be a Subversion revision > > number, but I'm not happy to go for a SNAPSHOT-style date/time: try > > telling someone your latest version is "3.6.0.20110507170144". > A SNAPSHOT is not a release and ideally should never be spoken off outside > the immediate team and even then you need to explain what a SNAPSHOT > does and does not yet do and what are the restrictions on its use and where > it does not respect the specifications. Or you can just let the other team > members curse you out when they spend hours trying to find out why their > software does not work when they use your SNAPSHOTs. > > SNAPSHOTS are very useful but version 1.3.5.6 is not the same as 1.3.5.6- > SNAPSHOT. > One comes with a warranty and the other comes with a warning.
Absolutely, but therein lies the problem. If we were to use SNAPSHOT, it would be 1.3.5-SNAPSHOT. In Maven terminology, this would result in you eventually 'releasing' a 1.3.5-SNAPSHOT as version 1.3.5. Our problem is that the builds that get tested are, presumably, SNAPSHOT builds of each of the components modified since the last project release. The 'Maven way' of doing this appears to be for every candidate for project release, I 'release' every component. If the testing fails (or a product manager changes his mind about how a feature should work, e.g. from beta feedback) then we would wind up 'releasing' each component modified in making that change before we had a build that could again be a 'release candidate'. Is that correct? This seems to make Maven 'release' more of a 'make-release-candidate' - and really quite time-consuming. This isn't a Web application - this is a 60-component medical imaging workstation, and the component dependency graph is deep rather than broad. A change can be only a line of code but still result in a rebuild of many components. Maybe the idea is that one can 'release' all of the components after testing? My major concern is trying to convince our quality team that having built the application against one set of versions that another set of versions are fundamentally identical. Is there some way for me to check that a component's build-time transitive dependencies' versions were all 'released'? > > What I want, therefore, is a system in which, for a set of top-level > > components to be built, it would then evaluate the set of transitive > > dependencies of those components as specified in Subversion (not Nexus > or > > the local repository), work out the complete list of out-of-date > components > > to build and then build all of those components such that the top-level > > components represent the current state of Subversion. Plainly, if the build > > is up-to-date with Subversion, nothing should be built. > > > Too much work. Just run a clean development workflow and do things the > Maven way and your life will be much more pleasant and your development > team much happier with each other. > Guys who release crap will soon find out that their friends will jump on > them and the boss will know that a crappy piece of software was released > when it was still at the SNAPSHOT stage. Alas, this is a large project but not a large team, and many components do not have single ownership because there just aren't enough people to do that. There are five of us across three projects and the component versioning process is a means to allow us to manage this size of project. I have to be absolutely sure that each check-in that any of us made has made it to the installer. I currently do this manually, and it's very time-consuming and error-prone (particularly since we're on CVS, so I can't just look at the revision log since the last build...). If a change has occurred a long way down the dependency tree, it needs a way to propagate upwards. I am trying to find out what the 'Maven way' is for each of these issues, but there has to be flexibility. Maven is the closest thing out there to the system we have right now, and I would much prefer to use it than to bolt on additional functionality to our large Ant script collection... but if it won't fit our organization, then it is Maven that will go. Thanks, David --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
