I know - yet another survey type email.  After the last one, I could
sleep better at night knowing we're not barking up some strange,
difficult tree with the config file question.

 

So the next question is focused on those using Cruise Control and maven
2.

 

Initially, if a large product was being built via CC+M2, the only
version we'd get of any of the dependencies (internal ones) were the
ones generated by CC (which also did mvn deploy:deploy).  

 

What we did for another internal project was everyone could set the main
project pom to use snapshots and any of the dependencies (which lived
outside of the main structure) to snapshots.  Build locally, then check
in from the lowest level up (and CC would supply the label in the proper
format).  Then, at the highest level necessary, you'd enter the version
of the CC supplied dependency you'd like.  This allowed us to keep using
true version numbers AND allowed people to take advantage of snapshots
locally for quick turn around testing.  Few understood and more often
than not, there'd be issues.

 

For a smaller internal project, we moved everything to using snapshots.
The tricky part is, the deployable units are all named
major.minor-SNAPSHOT.

 

When it comes down to release time, how are people migrating from
snapshots to releases?  Our release numbering scheme has always been in
a major.minor.patch.build-number format.  Toward the end of a release
cycle, we build multiple times.  What I don't want to have happen is
needing release engineering to spin each and every build by hand when
it's deemed a releasable version (I'm very happy having CC spin up our
other deployable units).  Plus, it gives QA the ability to say, "Found
in build 1.1.0.27" and "Fixed in build 1.1.0.32".  Versus "Found in
build 1.0-SNAPSHOT" and "Fixed in build <sometimestamp>".  Are people
building/testing/etc by hand in release engineering?

 

I'd love to know what people are truly doing.

 

 

Reply via email to