wood burning stoves 2.0*
The moose likes OO, Patterns, UML and Refactoring and the fly likes Version/release maintainance Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Version/release maintainance" Watch "Version/release maintainance" New topic
Author

Version/release maintainance

kundan varma
Ranch Hand

Joined: Mar 08, 2004
Posts: 322
Hi All,
Can somebody tell me what to do in scenariao given below.
Scenario - There are 40 functionality in release 1 of a module. This module goes to QA team and they found major bugs. By this time developers are working on functionality 41,42...so on. Now how to maintain version here??
If i fix QA bugs in 1st release then how to incorporate it in second release i.e having functionlity 41,42... . I am confused how to maintain code here. Can some body give some input???
Thanks,
kundan


SCJP1.4,SCBCD,SCEA,CNA
Failures are practice shoots for success.
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
My team has had QA at the end of the cycle, right before release, for a decade or so. I've never gotten an answer that I like regarding what the purpose is. The schedule shows no more iterations for fixing anything so I figure that all QA can do is stop a release. In fact they find bugs and we rush around with ad-hoc patches outside the official "process." Yuck. My conclusion is that QA at the end of the development cycle is doomed to create the kind of chaos you are worried about.

The agile methods all run user acceptance tests as they go as the measure of when a story is "done". If the tests find a defect you're not done yet and you fix things up before going on to the next story. If your stories are small enough the fixes are usually very small, too.

If your tests are automated you can rerun them often to make sure a new story didn't break an older one. The "QA at the end of the cycle" just goes away. Whew.

Is that useful? Try to build in continuous testing and make the "QA cycle" disappear. Our QA team is not going away, so I think the goal should be to make them redundant ... pass all the tests before code gets to them so they can't fail in QA.


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Balazs Borbely
Ranch Hand

Joined: Oct 11, 2004
Posts: 33
You can tag the version which is released to QA. If the QA founds bugs,
any time you can make a branch from that tag and fix it, and give it back to QA for retesting.

BUT those fixes should be added to the HEAD version as well.


'Make everything as simple as possible, but not simpler.' --Albert Einstein
kundan varma
Ranch Hand

Joined: Mar 08, 2004
Posts: 322
Hi Balazs Borbely ,
Can you explain more.What is head version. If i create a branch then how to maintain new functionality and bugs on previous functionality. I have to work twice to merge files or what??
Thanks,
kundan
Kishore Dandu
Ranch Hand

Joined: Jul 10, 2001
Posts: 1934
Please look into aspects called branches, labels.

Merging twice, thrice etc is part and parcel of day to day complex development efforts.


Kishore
SCJP, blog
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Kishore Dandu:
Merging twice, thrice etc is part and parcel of day to day complex development efforts.


Unfortunately, yes. Maintaining branches really is painful.

Much more effective is it to have QA not find bugs, because there aren't any. http://www.xprogramming.com/xpmag/jatQAonTeam.htm


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Was that really just put up today? Cool.

Branching almost always looks like this:


Branches are a pain. We now use a version control tool that requires us to label some version of each file for each release number. We're working on two releases at once so sometimes you check in a file and label it for N, sometimes N+1 and sometimes both. If N and N+1 are not identical and you want to make a change for both releases you have to check out each one, change it and check it back in with the right label. The build tool checks out by label so to build for N it gets all the N files and only the N files. Many opportunities for error.
kundan varma
Ranch Hand

Joined: Mar 08, 2004
Posts: 322
Thanks Stan, You are really good in explaining anything.
Thanks,
kundan
kundan varma
Ranch Hand

Joined: Mar 08, 2004
Posts: 322
Hi Stan,
What is the exact difference between branching and labeling. When to use branch and when to use label.
Thanks,
kundan
kundan varma
Ranch Hand

Joined: Mar 08, 2004
Posts: 322
I use PVCS
Kishore Dandu
Ranch Hand

Joined: Jul 10, 2001
Posts: 1934
Originally posted by Ilja Preuss:


Unfortunately, yes. Maintaining branches really is painful.

Much more effective is it to have QA not find bugs, because there aren't any. http://www.xprogramming.com/xpmag/jatQAonTeam.htm


THis is never possible. Even with XP. Bugs are going to arise some time or other after going to production(unless you are developing simple stuff)
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Kishore Dandu:

THis is never possible. Even with XP. Bugs are going to arise some time or other after going to production(unless you are developing simple stuff)


Yes, there are going to be bugs. But there don't have to be more than a handful a year, as experience of some teams out there show.

And the bugs don't just arise after some time, simply because we are working on non-simple stuff. They are found in production because we didn't write the right tests during development.
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
And bugs don't have to result in branches and patches. If you (can) release frequently any bug can just go into the next release.

Labeling is just a technique for keeping track of branches. It's an optional feature in Borland's StarTeam. I'm not fond of the way it does labeling; it's very easy to check in changes and forget to update the label so the next build doesn't pick it up. And I haven't figured out how to check things in while in a particular label view. But it's far better than holding patch versions of code private, e-mailing them to the build crew, etc.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Stan James:
If you (can) release frequently any bug can just go into the next release.


And the fix for the bug into the release after that...

But this actually is a good point - the reason for branching isn't that we need to fix bugs, but that our customers fear that together with the fix they will also get new bugs.

Producing high quality code with which that doesn't typically happen really is the superior strategy.
[ February 25, 2006: Message edited by: Ilja Preuss ]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Version/release maintainance