> > In this manner the release process itself substitutes as the quality > > assurance. > > In fact, in the early days of Tiles we did like this, but, in fact, > the "resolved" state is still without meaning. > Suppose that a build fails, you have to declare the version "invalid" > and move all the issues to another version. This step is needed even > if you use "resolved" state.
I don't quite understand you. In this context what do you mean the "build failed" ? And why would the issue be invalid? > >> Not necessarily. If you like, you can deploy a snapshot (mvn deploy), > >> let the other project depend on the snapshot > > > > I'm not very fond of inheriting from SNAPSHOT parents. Apart from the > > project instability it introduces it also slows down every build. > > Ok for the instability, but it is resolved when it is released thanks > to the Maven release plugin that checks the presence of snapshots. Yes of course. thanks for your patience. Then I've made the commit so to use 2-SNAPSHOT, and i'll update the site latter today. ~mck -- To mess up a Linux box, you need to work at it; to mess up your Windows box, you just need to work on it. | http://semb.wever.org | http://sesat.no | http://finn.no |
signature.asc
Description: This is a digitally signed message part
