Here is what worked best for me in past few projects (App Exchange apps)
Initially have these two orgs:
Dev Org ( Type = Partner Dev Edition) : Used for actual developement.
Packaging Org ( Type = Partner Dev Edition): Used for uploading the managed released package to app exchange with a unique namespace prefix.
Dev org will be used by any number of developers working on the project. I don't suggest using different orgs for each developer, as merging back everything and making sure no one kills other is very tough and time wastage.
Once you feel something is stable and ready for QA/Testing teams to verify, then their could be a couple of approaches
Register a namespace prefix and upload a managed beta package from Dev Org, and give it to testing team. I am suggesting using managed beta because:
- It doesn't locks any metadata in Dev org, so developers can remove or change anything
- It gives good versioning support, that can be used by QA team to report bugs against and track the package stability.
- Managed beta package with prefix is something what the actual AppExchange package would be, so its better to test it in the same format.
Testing team now can spawn new Orgs of required type from Partner Portal account, for ex. if you are targeting PE orgs, testers can spawn a PE org and install/test package out there.
Some guys don't like to pollute the Dev org with namespace prefixes, so for those cases you can push the code via Eclipse or Force.com migration tool (ANT) to another temporary Partner Development org, just to release the package for testing.
Rest of the stuff remains same as Approach 1
Push the code changes to Packaging org, and spawn a managed beta package for testers. Rest of the steps reamin the same as Approach 1.
In any of the above approach, Once the testing is done and you are ready for show time you can upload the package as managed released from the packaging org. Please note this will lock down metadata components included in the package, so take good care before taking this step.
Working with upgrades
Lets say you released version 1 of your app using any of the approaches indicated above. Your developers might have started development on phase 2 requirements in Dev org to release version 2 in few months.
You will realize the benefit of having packaging org, if some bugs came out in version 1 of app, and that needs to be fixed asap. It might be possible that your Dev org code base has changed and is not ready for packaging, because of many unstable version 2 changes.
Here one can make use of packaging org to fix the bugs in version 1 code base, and replicate the same with required code changes in Dev Org. So this way you can freely fix the version 1 bugs and release upgrades to your customers, and in the mean while the version 2 development will not be hampered.
seems too much text above, HTH :) !