Skip to main content
Software Engineering

You are not logged in. Your edit will be placed in a queue until it is peer reviewed.

We welcome edits that make the post easier to understand and more valuable for readers. Because community members review edits, please try to make the post substantially better than how you found it, for example, by fixing grammar or adding additional resources and hyperlinks.

Required fields*

5
  • "Versioning" is important, indeed, but when one tries to solve the described problem by freezing the core before a release, then you easily end up with the need for sophisticated branching & merging. The reasoning is that during a "release build" phase of team A, A might have to change the core (at least for bugfixing), but won't accept changes to the core from other teams - so you end up with one branch of the core per team, to be merged "later", which is a form of technical debt. That's sometimes ok, but often it just postpones the described problem to a later point in time. Commented Jun 12, 2014 at 13:49
  • @DocBrown: I agree with you, but I wrote under the assumption that all developers are cooperative and grown-up. This is not to say I have not seen what you describe. But a key part of making a system reliable is, well, striving for stability. Furthermore, if team A needs to change X in the core, and team B needs to change X in the core, then maybe X does not belong in the core; I think that is my other point. :) Commented Jun 12, 2014 at 13:58
  • @DocBrown Yes, we learned to use one branch of the core for each customer project. This caused some other problems. For example we don't like to 'touch' already deployed customer systems. As a result, they might encounter several minor version jumps of their used core after each deployment. Commented Jun 12, 2014 at 13:58
  • @SDD64: that's exactly what I am saying - not integrating changes immediately to a common core is no solution in the long term as well. What you need is a better testing strategy for your core - with automatic and manual tests as well . Commented Jun 12, 2014 at 14:04
  • 1
    For the record, I am not advocating a separate core for each team, nor denying that tests are required -- but a core test and its implementation can change at the same time, as I commented before. Only a frozen core, marked by a release string or a commit tag, can be relied upon by a project that builds on top of it (excluding bug fixes and provided that the versioning policy is sound). Commented Jun 12, 2014 at 14:25