> > Only my stuff can be a SNAPSHOT and it is either all a snapshot or it is > not. So, if B & C are mine it's not an issue, if they belong to some one > else's, they can't be SNAPSHOTs, it's that simple. I can even use the > enforcer to ensure there isn't a SNAPSHOT set anywhere as part of the > inspection process. >
This goes back to my original example. In large development teams it is very common for different groups to work on different modules which must all be integrated together for the application to work. In those situations it is common for all of the modules to change quite regularly. As a result, you want each of those teams to use snapshots because it's too painful to be always creating new release versions and update the pom files by hand. But you also don't want to throw away the testing you do with those snapshots. This is what motivates the idea of including enough metadata with the snapshots so that the binaries can ultimately be released *if required.* > We release by changing one entry in one POM and all of our stuff gets > versioned, built and released. Repeat the process and everything is back > to the next SNAPSHOT so we can resume changing things. It seems it is > this one discreet activity that CD abhors. You want to defer it to after > the fact which doesn't seem any different than what Stephen suggested by > waiting for CI feedback and then trigger a CD build. I don't get what > event prompts you to wan to go back and reproduce a build to be a > release? > But if you are continuously integrating the modules, which you should be (CI applies at the module level, not just at the code level), then you'd be changing the POMs *all the time*. > The ours vs. theirs problem exist for your plugin scenario too. Sure > you've created a synthetic POM but have they? If B & C's development is > in fact decoupled from yours, why would they? How would they know? If > they didn't make one and in turn are using SNAPSHOT deps themselves then > you're hosed and your problem is spiraling in complexity. > If creating the extra metadata is built in to the tool, then we ensure that everybody has the pom with the extra metadata and there isn't a problem. Anyone who doesn't need it can ignore it. > If your goal is to change anything anywhere at anytime and still deliver > any of it, good luck. No, that's absolutely not my goal. I want to make what I think is a very simple change to the way Maven works so that people can carry on with their existing methodology, but incrementally create a full deployment pipeline too if they find it to be valuable. -- Jez Humble Co-author, *Continuous Delivery <http://continuousdelivery.com/>* http://continuousdelivery.com/ http://jezhumble.net/ -- View this message in context: http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3255726.html Sent from the Maven - Users mailing list archive at Nabble.com.
