Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm working on a project that has frequent changes on the database and the implementation layers. I was releasing both the code and the database under the same release version, but since the database changes are more frequent than the core implementation, I'm thinking of separating their release/plan.

Is this the normal way to do it?

share|improve this question

migrated from May 30 '11 at 22:11

This question came from our site for project managers.

@Yehia, Welcome to the Site! It would help people answer your question if you edited your title to focus on the release plan itself (e.g. "Different Release Plan for Database and Implementation Layer") and give a little more information about the team working on the project. Are you working alone or are other people on the project? Who is the "client" on the project and do they have any requirements on the timing of the release plan? – Mark Phillips May 30 '11 at 14:40
Maybe a question to SO instead of PM? – Tiago Cardoso May 30 '11 at 18:22
Actually, I was thinking more along the lines of Programmers SE. Stack Overflow is for programming questions that include lines of code whereas Programmers SE is more about questions that are subjective, like this one, which really has no right or wrong answer. – jmort253 May 30 '11 at 18:25
@jmort253 It should be fine for Programmers. Feel free to migrate. – Adam Lear May 30 '11 at 22:02
yea i'm talking about releases so i think it would fit better in the PM website, anyways i got the answers am looking for thanks – Yehia A.Salam Jun 1 '11 at 8:49
up vote 1 down vote accepted

The purpose of a database is precisely to allow you to keep things separate. So while you don't have to, you can.

The requirement really boils down to what you need, taking into consideration what the best method is to save time wherever practical.

I have worked on a system for which we completely de-coupled database changes from application changes. In fact we made a point of not doing both at once unless necessary (or unless the whole point of the application change was to introduce new capabilities in the database). The reason for trying not to do both at once was to minimise risks of anything going wrong and needing to reverse the installation. The more you change at once, the higher the risk. But that was Air Traffic Control, so we were careful. It all depends on your own circumstances and end user requirements.

The way we resolved versioning is that each database version was also tagged with the application version. Our application versions were such that we knew just by looking at the version numbers whether the database was compatible or not (i.e. major versions were DB changes, minor versions within a same major version were all DB compatible). No matter what your scheme is, you need one that is easy to read & track.

share|improve this answer

If it works for your system then there's nothing wrong with having separate release plans for the database and the application.

However, it might make things difficult when it comes to ensuring that you get compatible versions of the database and application. You'll have to maintain a list of which version(s) of the database are supported by which version of the application. It's far simpler to have the same version number for both. Then all you need to do is check that they match and you know that they'll work together.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.