-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 My thought as well - Hudson would have each branch (as well as trunk) using a separate repository (config option).
Johan Dan Tran wrote: > My team is about to venture into this situation, my plan is to have > each team should have its own internal repo. Each team must > periodically merge into the main trunk which should also has its own > internal repo. We only cut a release at the main trunk. > > -D > > > > On Sun, Nov 16, 2008 at 12:25 PM, stug23 <[EMAIL PROTECTED]> wrote: >> Am I the only one with this question? >> >> >> stug23 wrote: >>> My question is related to the situation where there are multiple teams >>> working on the same project. Let's call the project 'foo-bar' >>> >>> For example, Team A is working on a Subversion branch called 'team-a' and >>> Team B is working on another Subversion branch called 'team-b'. >>> >>> The builds are automatically deployed to a shared Maven repo via Hudson >>> build jobs. So there is a Hudson build job watching Team A's branch and >>> another job watching Team B's branch. Obviously the two Maven builds will >>> need to have different versions in order to make this work so that the >>> deployed artifacts are distinct. These build jobs are of course working >>> with SNAPSHOT versions. >>> >>> So what is a good convention for this? Would something like this make >>> sense? >>> >>> Team A ==> com.foo:foo-bar:1.0-team-a-SNAPSHOT >>> >>> Team B ==> com.foo:foo-bar:1.0-team-b-SNAPSHOT >>> >>> Ultimately each of the separate Teams will merge/reintegrate their work >>> back onto the trunk. At this point they would need to "clean up" their >>> versions. For example, >>> >>> Team A finishes their work and reintegrates onto trunk with a final >>> version of: >>> >>> com.foo:foo-bar:1.0-SNAPSHOT >>> >>> Some time later Team B finishes their work and reintegrates onto trunk >>> with a final version of: >>> >>> com.foo:foo-bar:1.0-SNAPSHOT >>> >>> Then we release from trunk as: >>> >>> com.foo:foo-bar:1.0 >>> >>> Does this make sense? Or is there a better way to handle this parallel >>> development scenario? >>> >>> TIA >>> >>> >>> >>> >> -- >> View this message in context: http://www.nabble.com/Advice-on-version-conventions-for-parallel%2C-multi-team-development-tp20490312p20529587.html >> Sent from the Maven - Users mailing list archive at Nabble.com. >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - -- you too? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJIJiFpHYnED7evioRAlMVAJwJ/OIYJzjwgTN9Jbyx8TqfLHmkyACeM/lT TSaOyP6F7vT+Dw95aFomAZQ= =XF8b -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
