For example,
The current <version/> should be 40.0 (Summer '17).
However, the latest MavensMate (v0.0.11-beta.7) uses 34.0.

  1. What are some best practices for updating <version/> in package.xml in a code repository (such as BitBucket) when the whole team uses MavensMate for coding?

  2. How frequently is it recommended to update <version/>?
    Is it recommended to update it with every release (thrice a year)?

  1. To my knowledge, there is only the manual way to update package.xml for mavensmate - if setting the api version in mavensmate settings does not work to your expectations. Personally, I use CumulusCI for most package.xml related tasks. CCI lets me choose for which API version to build the package XML on project level.

  2. As best practice, I recommend avoiding updating to a new API Version without due cause. That means: If you don't need to update, don't.

  • (1) If you manually update <version/>34.0<version/> to <version/>40.0<version/>, Mavensmate remembers the older package.xml file. E.g., try to manually add a new class in the package which wasn't there before, and it won't be fetched by Mavensmate. It starts working again when you revert version back to 34.0. (2) I agree and upvote your idea to AVOID updating to new <version/> without due cause, even though it sounds bad. – Shumon Saha Jul 24 '17 at 17:29
  • 1
    Have you set the api version in Mavensmate settings? – Christian Szandor Knapp Jul 24 '17 at 17:58
  • Nope not working. I tried replacing both: API version in Mavensmate settings to 40.0 and package.xml to 40.0. I deleted all files locally (except package.xml) and refreshed from server - and package.xml automatically reverted to 34.0. I repeated the experiment with 39.0 and package.xml was again reverted to 34.0. – Shumon Saha Jul 24 '17 at 19:31
  • 1
    Sorry to hear, then Im out of ideas. For what it's worth, I've ditched Atom+MM in favour of VS Code + ForceCode – Christian Szandor Knapp Jul 24 '17 at 20:53
  • 1
    API version in Mavensmate settings works in stable Mavensmate, but doesn't work in Mavensmate beta. – Shumon Saha Jan 26 '18 at 9:14

There are two places where the API version matters.

  • src/package.xml
  • MavensMate Global Settings

You already know about src/package.xml, but you should also know that when MavensMate deploys or retrieves a package, it's actually invoking the API version defined in Global Settings. See screenshot below.

MavensMate Global Settings Salesforce API Version

Once you make both changes you're good to go. One consideration if you're using a version control system like Git: When upgrading the package, you'll want to create a pull request that takes your package as-is and upgrades it to the new version. This will keep your commit history clean and clearly show the upgrade in-place with no modifications to functionality.

  • If you delete all folders from SRC locally (only keeping package.xml), and then right-click SRC and refresh from server, does package.xml stay on 39.0 or revert to 34.0? Mine reverts to 34.0 despite following the two bullet points you mentioned. – Shumon Saha Jul 26 '17 at 7:42
  • Check your Global Settings, @ShumonSaha. And the API version looks right there, then re-authenticate with MavensMate to start a new session on the right API version. – Marty C. Apr 3 '18 at 18:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.