Whomever your release-engineers, qa.. etc.. the post-development people are, incremental releases are annoying.

That hasn't been my experience - people usually thank me for regular incremental releases :-) A few things to consider:

• Just because there are regular updates doesn't mean you need to use them. I don't go around every live project and update modules every time a new release comes out. Release and integration are independent tasks.
• If integrating code is causing problems spend some time figuring out why. You can often make it easier (e.g. one of my dev boxes happily updates from CPAN every day, runs the test suites on all my code and mails me if it comes across any problems - no manual intervention needed.)
• Incremental releases means that you can practice your QA and integration tasks more if you wish. People get better with practice.
• Incremental releases mean more bug fixes are available sooner. The sooner I get a bug fix the more time I have for integration and regression testing. More time is good.
• Incremental releases mean you get more opportunities to re-prioritise. You can lobby to get the patches that are more important to you done earlier.
• Small releases are easier to schedule, so are more likely to come out on time - making the work of QA and integration people much easier to plan.

Doing something once in a while with a lot of work feels a lot nicer than doing a little bit less work often.

It can do. It can also be a complete pain. I come across reactions of the "You want us to do what by when?!?!" variety a lot more than "Please stop giving me these small bits of work".

# Incremental releases means that you can practice your QA and integration tasks more if you wish. People get better with practice. # Incremental releases mean more bug fixes are available sooner. The sooner I get a bug fix the more time I have for integration and regression testing. More time is good. # Incremental releases mean you get more opportunities to re-prioritise. You can lobby to get the patches that are more important to you done earlier. # Small releases are easier to schedule, so are more likely to come out on time - making the work of QA and integration people much easier to plan.

Nooooooooooo! If you change your code, then you need to test all the parts it touches. That means every nook and crany has to be looked at over and over. A big PITA. Incremental or long term releases (1 month, 2 months.. whatever) resolves the same # of bugs. If you can accumulate an amount of bugs over a month or over 30 seperate days, fixing them on schedule, you fix the same amount of bugs. Smaller releases are easy to schedule for the developer and QA, but it doesn't mean qa et al will be able to turn around in a day. If a release takes QA a week to test minimally, trying to squash it to a day or two only hurts them.

Play that funky music white boy..

Nooooooooooo! If you change your code, then you need to test all the parts it touches.

As I said before:

Just because there are regular updates doesn't mean you need to use them. I don't go around every live project and update modules every time a new release comes out. Release and integration are independent tasks.

Just because there are many releases doesn't mean you have to integrate every one. If you need the features / bug fixes you integrate. If you don't wait. They are independent tasks and can be scheduled appropriately.

That said, I would still recommend integrating as often as possible for the other reasons mentioned.

That means every nook and crany has to be looked at over and over. A big PITA.

As I said before:

If integrating code is causing problems spend some time figuring out why. You can often make it easier

This is what regression tests, acceptance tests, etc. are for. I run all my integration tests several times a day. Microsoft build their apps daily.

Obviously before a full public release of a public application you'll go through a slightly more extensive testing period. However if you're QA group cannot integrate minor updates in less than a week you should buy them some books and get some consultants in to train them up in some more modern practices.

If you can accumulate an amount of bugs over a month or over 30 seperate days, fixing them on schedule, you fix the same amount of bugs

But do you fix the same bugs? If you release more often you can re-order your priorities more often and respond to changes more quickly.

If a release takes QA a week to test minimally, trying to squash it to a day or two only hurts them.

In my experience when somebody says "We can only integrate once a month because it takes a week to do", it turns out in the end to mean "It takes a week to integrate because we only do it once a month".

An integration and testing process that happens once a month is built up around bulk changes, testing many new features, dealing with many integration failures, feeding large amounts of feedback back to the developer, etc.

If you do it more often you're dealing with fewer changes, fewer features, fewer integration failures, less information, tighter feedback loops, etc.

In most cases the more often you do it the faster it gets.

QA only (should get) gets it when its actually released for a customer, which they then test together with other actual product releases meant to be delivered to a customer.

At least, thats how the $company I work for does it. Eg the defect/feature/whatever is 'finished' from the developers point of view.

I'd say, you're both right.

C.