Re: Advice on version conventions for parallel, multi-team development
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]
Re: Advice on version conventions for parallel, multi-team development
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]
Re: Advice on version conventions for parallel, multi-team development
-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]
