0

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)?

2 Answers 2

1
  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.

6
  • (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. Jul 24, 2017 at 17:29
  • 1
    Have you set the api version in Mavensmate settings? Jul 24, 2017 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. Jul 24, 2017 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 Jul 24, 2017 at 20:53
  • 1
    API version in Mavensmate settings works in stable Mavensmate, but doesn't work in Mavensmate beta. Jan 26, 2018 at 9:14
1

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.

2
  • 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. Jul 26, 2017 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, 2018 at 18:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .