in-house projects: to stable release or not?

Question

Suppose you work at a medium-to-large software company with many independently-developed projects (independent coders) but which rely on each other (dependent code).

If it were up to you, would you make sure each project produced stable branches so that the other projects could more reliably use those branches, or would you encourage projects to directly use the latest-available code from other projects?

The advantage of a stable release is clear to me - a higher probability that your dependencies will work as advertized. Yet I can also see some good points to avoiding stable releases - each project has a little less work to do, and you can react very quickly to bugs that affect everyone, since your code is sort-of auto-updating all the time. For example, imagine there's a subtle security flaw at timestamp X in one in-house library - it might not be noticed until that code is widely used. If you're using stable release branches, you'll have to get every other project to modify their dependencies to effect the security fix. Without release branches, the fix is picked up immediately in the next build of all other projects.

I'm especially interested if anyone has industry experience with both alternatives.

Answer 1

Looking at other projects, it seems to me that the issue that you raise is addressed by having security branches. E.g. Debian packages. That way, you would continue using stable branch across projects. For the reasons you mention, testing / work-in-progress branches carry too much risk.

Answer 2

Think it really breaks down to how mission critical the software is. If you can put up with mild crashing and maybe some data corruption and it's easy to push new builds, running unstable code might be preferred. Now if lives or reputations depend on everything working correctly, or if pushing a new build is a major process, stable tested releases are the only way to go.

Answer 3

As always, there are pros and cons for each of the options.

Using branches may be more stable but it requires more maintenance when you're required to update to a newer branch. It also requires their development team to spent extra time when the branch is merged with the trunk.

On the other hand, using the trunk may force you to deal with other people's bugs and write messy workaround code to get around it. It may get especially messy if you get weird OutOfMemory/Performance issues that can't be pinned to a specific library (or your own code). Remember that this isn't your code, and you probably don't have the manpower to help them with their QA efforts...

So I guess the final word on this is that it depends. I would suggest taking these factors into consideration:

1. Is the API you're using going to change?
2. Is it important to work on "clean code" or can you allow yourself to mess around with other people's bugs?
3. Is it crucial for the application to use the "cutting-edge" version of the libraries?

As a side note, and from experience, I can tell you that one of our programmers missed a couple of nights' sleep because he worked with branches and the upgrade to a newer branch changed the entire API and logic. :)

HTH