The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Working on multiple releases (phases)

We are a team working on a medium-sized project, which is been divided into several releases (let me hereby say that as Phases). For the first time, we found ourselves working on two releases simultaneosly. We are using VSS for version controlling.

Phase 1.0 is gone for acceptance testing. Phase 2.0 development has already started. Now, there are some bugs (or minor changes) to be done for phase 1.0. How do we handle this situation?
Tuesday, February 14, 2006
Oops...Did not mention the tools we are using...VS.NET 2003 with VSS (yeah, I did mention this one:-)).
Tuesday, February 14, 2006
I have never heard an answer to this question that did not upon close inspection work without a bunch of handholding.
NetFreak Send private email
Tuesday, February 14, 2006
Under this scenario we will make a branch from 1.0. After we done with 1.0 we merge back to the main branch.
Tuesday, February 14, 2006
Simulatneous development on multiple releases pretty much requires branching at the release point.

You can have people hold changes in their area for a very long time. Bad idea.

You can have people check-in the next release features now. Bad idea.
son of parnas
Tuesday, February 14, 2006
I don't think there are any silver bullet solutions to your problem. Just concentrate really hard on every check-in you do on both versions until you are back on serial development.

I used to know a project where teams were split based on release version. V1 would be under test and a bug report would be raised against it. A copy of the bug would also be copied to the V2 team. From that point onward there would be two completely different fixes in the code base for the same bug!

It's tempting to introduce parallel development try claw back time against slipping timescales, but I suspect any obvious benefit is negated by the unseen problems it causes.
IanH. Send private email
Tuesday, February 14, 2006
1. Pick up a copy of one of the Pragmatic Programmer books on version control.

2. VSS is not your friend in this situation.  You'll have to devise a workaround that is likely to be time-consuming and ugly.

3. Because of #2, it would be helpful to devise a checklist of actions that must be taken upon fixing a bug in one release stream or the other.  If the devs don't follow it, start breaking toes (they'll need their fingers to work)

Another good book to own is "Software Configuration Management Patterns: Effective Teamwork, Practical Integration" by Stephen P. Berczuk and Brad Appleton
example Send private email
Tuesday, February 14, 2006
V1 SHOULD already be on a branch. Make bufixes on the branch, merge back into the main bracnh (which is what V2 will be from).

When the time comes that you have pretty much everything in place for V2, all that's left is packaging, testing etc, branch out off of main for V2. Same procedure.
revert my buffer
Wednesday, February 15, 2006
Thank you all...

It seems branching is the only practical solution as of now.

Thanks a bunch again..

Thursday, February 16, 2006
WALRAD, Chuck and STROM, Darrel - "The Importance of Branching Models in SCM"

Feel free to contact me if you didn't find the article.
Davi Menezes Send private email
Wednesday, February 22, 2006

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz