On Nov 5, 2010, at 4:56 PM, Phillip Hellewell wrote: > I'm guessing you also update the parent pom's version each time the > dependency management section changes, yes?
Are you keeping in mind the impact that SNAPSHOT versions have on your build? A released version is like a point on a line or an instant in time, whereas snapshots are the distance between points. Snapshots can be for your own use only (with the 'install' goal) or to share with others who have access to a shared remote repository (with the 'deploy' goal). If I am using snapshots, I don't have to change the version every time I make a change, since someone else's build that depends on the snapshot I deployed to our shared repository will check that repository with every build to make sure it has the latest. In other words, if I deploy a new snapshot with a changed dependency management section, it will be picked up by others (including CI) when they run a build. I've found CI systems to be the easiest way to manage this complexity, but I haven't found a self-maintaining way to get them to trigger with the granularity necessary to just build based on changes. For instance, I can add one SCM repository trigger to a top-level build, but that just triggers CI to rebuild everything. I believe this is not what you want because if CI deploys new snapshots for everything, the binaries for everything built will look stale to all the developer desktops that share the repository that CI pushed to. On the other hand, if I have hundreds of modules and I need to create a separate SCM triggers for each one of them, the effort to maintain the build shoots way up. It would create the desired granularity, but I haven't had a case that this would be worth it yet. But I think your original observation of using version ranges is correct. Anyway, if you have a build that is this complex, you may need someone to wear the release management hat. Maven doesn't make the problem less complex, it just does most of the work for the solution. It won't stop people from having variations on what the correct answers are (i.e. when to change versions), hence the need to have a single authority that manages procedure the same way every build. Brian --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
