Apex Code Development You need to sign in to do that
Don't have an account?
Koen (BvD) Beta versus release - how to manage?
Hello,
I am working with a managed package, but am not sure how to use the beta and release versions. I have one account where I create the package and a second where I install it. It is in the second account that the testing is done. So on one hand I would have to create beta packages untill all testing is ready and then change it to release.
However there is a big nuisance in using beta packages in my case. You cannot upgrade beta packages, so you must first uninstall and then reinstall the package. To be able to uninstall you need to remove all references and you also lose all contents in custom objects. For the package I have and the references and content I create in the installed package, this makes a difference of installation time from 10 minutes to upgrade just to a new release version to 45 minutes when using beta packages (remove references, uninstall, install, create references in page layouts and user's default apps, creating content, ..)
So what is the correct way to use beta versions? Or am I just to use release versions? (But one aestatic aspect then is that the version is upped for every cycle)
Any suggestions?
Koen.
Hi,
What we do is, we create one org and do alll the coding into it - that is dev org.
and through manage-beta package we create a package and install it in another org say - stg org.
and finally create one trial org where we again install this package and so all the testing.
If testing is done then we change it to manage-release package.
I think you must be doing some other mistake, please check it once.
As this is the only procedure.
It really is a pain,
Beta in the appexchange world doesn't mean the same thing as Beta in the google world. Beta packages can't easily be used to test with understanding clients as there is no upgrade path from beta to production. The beta packages are really kind of useless for anything other than internal testing to make sure you don't lock in any unchangeble pieces.
Even worse is that sometimes you'll run into errors in a production package after you fully tested the beta package. Hopefully it'll get better but right now there's no real solid solution that I know of.
Cheers,
Scott
I wouldn't know a good solution, because I can understand that upgrade is not supported when you can change the name of classes and custom objects etc. Something that would do the trick for me partly is an intermediate concept. You could call it a release candidate. It would lock the objects and allow upgrade just like a release version, but it would stand out in your version history and people installing the package would still be "more understanding" with respect to problems occuring in your package.
Still, same as now I will end up never using the beta releases (just release and release candidates). An even better solution would be that if you follow the path 1.1 release --> 1.2 beta --> 1.2 release you would only need to uninstall the part of the package that was not already lccked in the 1.1 version as that part can't change anyway when migrating to 1.2
I don't understand why anyone would ever use a Beta package, even for Anjali's usage. Since you can't upgrade if you are using for testing why not deploy via an unmanaged package or, as I currently tend to do, via the ant tool?
Here's my current process:
(1) Dev org (code deployed via ant tool from dev org to deploy org)
(2) Deploy org in which initial QA / testing happens (code is made into a managed package when testing is complete and necessary for a release)
(3) Prod test org (managed package ends up here and there is additional QA)
(4) Prod org (managed package ends up here, once it is complete.
If there is a signficant problem w/ 3 I trash the dev org in (2) and start over with a new one and a new managed package.
I don't have much of a use for Sandbox orgs either, as it turns out.