Another rule of thumb is how stable are the tests... if you have a stable test suite that never fails randomly only to pass again next run... you can have a 1 hour long build and release that... it will take 2-3 hours for the release run to go through, but you know it will go through...
If you have a module with a test that has a 1 in 5 chance of failing... move that module out on its own (better is fix the test... but selenium tests can be permanently dodgy, as can some threading tests) that will probably leave you with A... B C... as your release roots, where A holds everything that can be built without building B... B is the one module with the dodgy tests and C is everything that needs B to be built. That way at least you only waste 5 min on a failed B release rather than 2-3 hours on the close to 50:50 chance that either of the two runs through B's tests will fail. On 24 May 2012 16:00, Thiessen, Todd (Todd) <tthies...@avaya.com> wrote: > I am on the same page as Ron here. But I know you will get a different > answer for different maven users. Just recently, someone was asking a > similar question on this list and he/she very much wanted one large checkout > where all modules have the same version and was against breaking it up into > individually versioned parts. > > It is a bit of an art to decide when a multi-module project becomes too > large. My rule of thumb is the 10 minute build. If building everything > takes longer than 10 minutes, it is time to think about breaking it up. > >> -----Original Message----- >> From: Ron Wheeler [mailto:rwhee...@artifact-software.com] >> Sent: Thursday, May 24, 2012 10:44 AM >> To: users@maven.apache.org >> Subject: Re: Maven versioning >> >> We started out with a "Yes". >> As the number of modules grew to over 70 and the reasons for new >> releases got more functionally oriented, we went to "No". >> >> Philosophically, we looked at our use of Apache libraries (and other >> third party libraries) and reasoned since we were very comfortable >> using >> third party libraries with version numbers that were different than our >> release, why should we be hung up on changing the version on something >> that did not change. >> >> We also moved to SOA as a major architectural foundation so changes to >> the database and the API for the basic objects started to have less >> impact on the presentation and business layer since the services >> isolated the impact of low level changes to only those modules that >> need >> to deal with the updated data elements. >> >> We went high-tech to manage the versions. >> A spreadsheet listing the modules down the rows and the version of the >> module that is used in each of the releases in the column for each >> release.;-) >> >> We have a team planning session at the start of each release to >> identify >> which modules will change. >> The definite need to look at each module in this initial stage as a >> team, also helps understand estimates and timelines a bit better. >> >> We are mostly right at the start but sometimes we get a surprise during >> development and have to update the spreadsheet. >> >> Saves hours of useless work and sometimes makes debugging a bit easier >> since you have a clearer idea about what module changed, when and why >> just by looking at the spreadsheet. >> >> Downside: A bit messy looking in deployment. >> >> We use Subversion and Eclipse STS so branching and tagging is >> available. >> >> Ron >> >> On 24/05/2012 8:39 AM, DK wrote: >> > Hi, >> > >> > New to Maven and have a couple of questions around versioning. >> > >> > Should all projects within a multi-module project have the same >> version? >> > >> > Should all projects related to each other keep the same version >> number? >> > >> > Any best practices on changing version numbers? >> > >> > Thanks >> > >> > -- >> > View this message in context: http://maven.40175.n5.nabble.com/Maven- >> versioning-tp5709659.html >> > Sent from the Maven - Users mailing list archive at Nabble.com. >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> > For additional commands, e-mail: users-h...@maven.apache.org >> > >> > >> >> >> -- >> Ron Wheeler President Artifact Software Inc email: >> rwhee...@artifact-software.com skype: ronaldmwheeler phone: >> 866-970-2435, ext 102 >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
