> Ron Wheeler wrote: > This is a common problem and when you quote the cost of > reporting-1, you need to include the cost of releasing > booking-1 with the new core library. > You can reduce the cost by breaking core onto multiple > smaller libraries that are less susceptible to change. > With small changes to large systems, the cost of the release > of a new system can be larger than the programming and > testing of the actual change.
I'll talk with the architect tomorrow or on monday about this issue, but I think this isn't an option. The Java-parts of our system are growing since about ten years and contains ~100 modules. Our team is relatively new at this occupation, but it's obvious, that in the last ten years nobody had the heart to touch the existing infrastructure, because it would cost huge amounts of money (I'm not familiar to details, but we heard numbers with more than five digits) just for QA. This results in adding here something and there around the infrastructural components or duplication with slight changes - uncontrolled growing... As a consequence we want to establish a new architecture beside the old one and learning from these issues. So the evolutionary development of the architecture is somehow crucial. > You create releases that you store in Nexus (or some other > repository). > In your SCM, you store your software with properly named > branches so that you can patch and rebuild anything that you If I understand you right, this is the way we thought about. Is it correct, that your suggestion would lead to the same goal: we wouldn't have the One release-branch containing the complete currently released code-base? In our approach the current released code-base is splitted across multiple branches. Stefan -- GMX DSL SOMMER-SPECIAL: Surf & Phone Flat 16.000 für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
