Mixing
Is there a way to upgrade api versions of all apex classes without manually updating each of them?
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
1
down vote
favorite
I have an org with hundreds of apex classes, all of which have api versions ranging between 30-37. Is there an easy way to bring them all to the latest api version at once without resorting to manual updates?
apex api-version
asked Aug 22 at 18:17
kabdelr00
404
add a comment |Â
up vote
1
down vote
favorite
I have an org with hundreds of apex classes, all of which have api versions ranging between 30-37. Is there an easy way to bring them all to the latest api version at once without resorting to manual updates?
apex api-version
asked Aug 22 at 18:17
kabdelr00
404
Do you have a reason to want to do that? One of the points of the versioning is so that older code can rely on the behavior that existed when it was written and new code can opt-in to newer features by using the latest API version. Changing all the classes to the latest version would require some testing to be done to check that nothing has broken.
– Keith C
Aug 22 at 18:35
add a comment |Â
up vote
1
down vote
favorite
up vote
1
down vote
favorite
I have an org with hundreds of apex classes, all of which have api versions ranging between 30-37. Is there an easy way to bring them all to the latest api version at once without resorting to manual updates?
apex api-version
asked Aug 22 at 18:17
kabdelr00
404
I have an org with hundreds of apex classes, all of which have api versions ranging between 30-37. Is there an easy way to bring them all to the latest api version at once without resorting to manual updates?
apex api-version
asked Aug 22 at 18:17
kabdelr00
404
asked Aug 22 at 18:17
kabdelr00
404
asked Aug 22 at 18:17
kabdelr00
404
asked Aug 22 at 18:17
kabdelr00
404
404
Do you have a reason to want to do that? One of the points of the versioning is so that older code can rely on the behavior that existed when it was written and new code can opt-in to newer features by using the latest API version. Changing all the classes to the latest version would require some testing to be done to check that nothing has broken.
– Keith C
Aug 22 at 18:35
add a comment |Â
Do you have a reason to want to do that? One of the points of the versioning is so that older code can rely on the behavior that existed when it was written and new code can opt-in to newer features by using the latest API version. Changing all the classes to the latest version would require some testing to be done to check that nothing has broken.
– Keith C
Aug 22 at 18:35
Do you have a reason to want to do that? One of the points of the versioning is so that older code can rely on the behavior that existed when it was written and new code can opt-in to newer features by using the latest API version. Changing all the classes to the latest version would require some testing to be done to check that nothing has broken.
– Keith C
Aug 22 at 18:35
Do you have a reason to want to do that? One of the points of the versioning is so that older code can rely on the behavior that existed when it was written and new code can opt-in to newer features by using the latest API version. Changing all the classes to the latest version would require some testing to be done to check that nothing has broken.
– Keith C
Aug 22 at 18:35
add a comment |Â
2 Answers
2
active
oldest
votes
up vote
4
down vote
accepted
WARNING
First of all, I would like to say, do this only if you are certain you have sufficient unit tests to catch anything that might break. Also, make certain you back up your code. I cannot stress this strongly enough.
You can do this pretty easily with any IDE, Salesforce DX, workbench, etc. The general process is either two or three steps.
First, download the files you want to update the API version for. Next, use a tool to "Find and Replace in Files". All major IDEs have this feature. Replace <apiVersion>.+</apiVersion> (a regular expression match) to the desired version. Third, if your IDE doesn't automatically deploy the changes, deploy the changes back to the server.
Force.com IDE (Search > File)
answered Aug 22 at 18:38
sfdcfox
225k10171384
add a comment |Â
up vote
3
down vote
Firstly, do heed sfdxfox's warning. It is very important to backup your metadata before embarking on such a large scale update of the api versions.
Make sure you run all the test cases before and after to look for things breaking. They might break in strange and unexpected ways.
If you can, try this out in a scratch org first so it is easy to experiment and roll back if required.
René Winkelmeyer has created a SFDX plugin that can automate this process for you. It will either target the highest version in the target org or you can specify a target version.
sfdx muenzpraeger:source:api:set -a 41.0
Reading content of package directories
45 files have been set to API version 41.0.
answered Aug 22 at 21:30
Daniel Ballinger
69.3k14140363
add a comment |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
4
down vote
accepted
WARNING
First of all, I would like to say, do this only if you are certain you have sufficient unit tests to catch anything that might break. Also, make certain you back up your code. I cannot stress this strongly enough.
You can do this pretty easily with any IDE, Salesforce DX, workbench, etc. The general process is either two or three steps.
First, download the files you want to update the API version for. Next, use a tool to "Find and Replace in Files". All major IDEs have this feature. Replace <apiVersion>.+</apiVersion> (a regular expression match) to the desired version. Third, if your IDE doesn't automatically deploy the changes, deploy the changes back to the server.
Force.com IDE (Search > File)
answered Aug 22 at 18:38
sfdcfox
225k10171384
add a comment |Â
up vote
4
down vote
accepted
WARNING
First of all, I would like to say, do this only if you are certain you have sufficient unit tests to catch anything that might break. Also, make certain you back up your code. I cannot stress this strongly enough.
You can do this pretty easily with any IDE, Salesforce DX, workbench, etc. The general process is either two or three steps.
First, download the files you want to update the API version for. Next, use a tool to "Find and Replace in Files". All major IDEs have this feature. Replace <apiVersion>.+</apiVersion> (a regular expression match) to the desired version. Third, if your IDE doesn't automatically deploy the changes, deploy the changes back to the server.
Force.com IDE (Search > File)
answered Aug 22 at 18:38
sfdcfox
225k10171384
add a comment |Â
up vote
4
down vote
accepted
up vote
4
down vote
accepted
WARNING
First of all, I would like to say, do this only if you are certain you have sufficient unit tests to catch anything that might break. Also, make certain you back up your code. I cannot stress this strongly enough.
You can do this pretty easily with any IDE, Salesforce DX, workbench, etc. The general process is either two or three steps.
First, download the files you want to update the API version for. Next, use a tool to "Find and Replace in Files". All major IDEs have this feature. Replace <apiVersion>.+</apiVersion> (a regular expression match) to the desired version. Third, if your IDE doesn't automatically deploy the changes, deploy the changes back to the server.
Force.com IDE (Search > File)
answered Aug 22 at 18:38
sfdcfox
225k10171384
WARNING
First of all, I would like to say, do this only if you are certain you have sufficient unit tests to catch anything that might break. Also, make certain you back up your code. I cannot stress this strongly enough.
You can do this pretty easily with any IDE, Salesforce DX, workbench, etc. The general process is either two or three steps.
First, download the files you want to update the API version for. Next, use a tool to "Find and Replace in Files". All major IDEs have this feature. Replace <apiVersion>.+</apiVersion> (a regular expression match) to the desired version. Third, if your IDE doesn't automatically deploy the changes, deploy the changes back to the server.
Force.com IDE (Search > File)
answered Aug 22 at 18:38
sfdcfox
225k10171384
edited Aug 22 at 18:43
answered Aug 22 at 18:38
sfdcfox
225k10171384
answered Aug 22 at 18:38
sfdcfox
225k10171384
answered Aug 22 at 18:38
sfdcfox
225k10171384
225k10171384
add a comment |Â
add a comment |Â
up vote
3
down vote
Firstly, do heed sfdxfox's warning. It is very important to backup your metadata before embarking on such a large scale update of the api versions.
Make sure you run all the test cases before and after to look for things breaking. They might break in strange and unexpected ways.
If you can, try this out in a scratch org first so it is easy to experiment and roll back if required.
René Winkelmeyer has created a SFDX plugin that can automate this process for you. It will either target the highest version in the target org or you can specify a target version.
sfdx muenzpraeger:source:api:set -a 41.0
Reading content of package directories
45 files have been set to API version 41.0.
answered Aug 22 at 21:30
Daniel Ballinger
69.3k14140363
add a comment |Â
up vote
3
down vote
Firstly, do heed sfdxfox's warning. It is very important to backup your metadata before embarking on such a large scale update of the api versions.
Make sure you run all the test cases before and after to look for things breaking. They might break in strange and unexpected ways.
If you can, try this out in a scratch org first so it is easy to experiment and roll back if required.
René Winkelmeyer has created a SFDX plugin that can automate this process for you. It will either target the highest version in the target org or you can specify a target version.
sfdx muenzpraeger:source:api:set -a 41.0
Reading content of package directories
45 files have been set to API version 41.0.
answered Aug 22 at 21:30
Daniel Ballinger
69.3k14140363
add a comment |Â
up vote
3
down vote
up vote
3
down vote
Firstly, do heed sfdxfox's warning. It is very important to backup your metadata before embarking on such a large scale update of the api versions.
Make sure you run all the test cases before and after to look for things breaking. They might break in strange and unexpected ways.
If you can, try this out in a scratch org first so it is easy to experiment and roll back if required.
René Winkelmeyer has created a SFDX plugin that can automate this process for you. It will either target the highest version in the target org or you can specify a target version.
sfdx muenzpraeger:source:api:set -a 41.0
Reading content of package directories
45 files have been set to API version 41.0.
answered Aug 22 at 21:30
Daniel Ballinger
69.3k14140363
Firstly, do heed sfdxfox's warning. It is very important to backup your metadata before embarking on such a large scale update of the api versions.
Make sure you run all the test cases before and after to look for things breaking. They might break in strange and unexpected ways.
If you can, try this out in a scratch org first so it is easy to experiment and roll back if required.
René Winkelmeyer has created a SFDX plugin that can automate this process for you. It will either target the highest version in the target org or you can specify a target version.
sfdx muenzpraeger:source:api:set -a 41.0
Reading content of package directories
45 files have been set to API version 41.0.
answered Aug 22 at 21:30
Daniel Ballinger
69.3k14140363
answered Aug 22 at 21:30
Daniel Ballinger
69.3k14140363
answered Aug 22 at 21:30
Daniel Ballinger
69.3k14140363
answered Aug 22 at 21:30
Daniel Ballinger
69.3k14140363
69.3k14140363
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsalesforce.stackexchange.com%2fquestions%2f229795%2fis-there-a-way-to-upgrade-api-versions-of-all-apex-classes-without-manually-upda%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Do you have a reason to want to do that? One of the points of the versioning is so that older code can rely on the behavior that existed when it was written and new code can opt-in to newer features by using the latest API version. Changing all the classes to the latest version would require some testing to be done to check that nothing has broken.
– Keith C
Aug 22 at 18:35