How to version your add-in

New requirements are a standard part of the development life cycle process and add-ins are no different. Requirements can be used to improve or add new functionality to existing add-ins. The add-in version model supports this typical step in the development life cycle. This topic explores how a developer can version an add-in and how it can be integrated into your development workflow.

In this topic

About versioning your add-ins

The following guides you through the process of deploying two different versions of the same add-in project. The project contains a single button that in version 1.0, prints a "Hello, World!" message and version 2.0 prints a "Hello, World! Version no. 2" message. Versioning is significant because you do not need to create two separate projects to achieve the preceding workflow. The same project can be re-used and re-deployed with the updates getting pushed to your users. Depending on the deployment method you choose and the various approaches, see How to deploy your add-in. The scenario will be illustrated in the following workflow.

Verifying the initial add-in project works

Assuming you have already created an add-in project following the instructions in How to create an add-in project in Eclipse and a button following the directions in How to create an add-in button, this step is a little redundant; however, still valuable in cases where there has been time between the first version and the update you are looking to do now. In addition, testing and ensuring functionality gives you a base moving forward with modifications. Here are some additional considerations for this step in the process:
To verify the add-in functionality, deploy the add-in, then test it. 

Making improvements or adding new functionality

Now that you have a snapshot of your first version of the add-in, the next step looks at implementing your new functional requirements or making improvements to existing functionality. In this step, make any of the changes that are required in your existing project. You do not need to create a project; access your existing project and make the necessary changes. The following are some additional considerations for this step in the workflow:
In the scenario described, you need to replace the line of code that defines the JOptionPane message dialog with the following string: "Hello, World! Version no. 2." for version 2.0 of the add-in project. The code will look like the following in your button’s onClick() method:
@Override public void onClick()throws IOException, AutomationException{
    JOptionPane.showMessageDialog(null, "Hello, World! Version no. 2.");
Save the changes you’ve made in Eclipse and proceed to the next step.

Changing the version number

In the add-in editor for your Eclipse project, a version property exists. The version property allows you to set the version number for your add-in project. By default, the first version is set to version 1.0; however, it is possible to version your add-in starting at 0.1 and working your way up to version 1.0. If you used the default version number when creating the add-in project initially, you can increment the version number to create a newer version of your add-in (for example, 1.1 or 2.0). The framework is flexible to both cases when increasing the version number of your add-in project. The convention used should follow the standard set in your organization.
For the previous scenario, change the version from 1.0 to 2.0 and save your Eclipse project.

Re-deploying the add-in

The following requires you to re-deploy your add-in using one of the methods described in How to deploy your add-in.

Testing your update

Open up the ArcGIS for Desktop application for which the add-in was designed and test it using the same workflow or workflows that you expect the users to follow. If the testing does not succeed, return to Eclipse and fix your code, re-deploy, and test again (note that on the second iteration you do not need to change the version number; this item only needs to be updated once in this workflow). The following are some considerations for this step of the process:

Sharing the new version

The following step requires you to distribute your add-in using one of the methods described in How to deploy your add-in.

Development licensingDeployment licensing
ArcGIS for Desktop BasicArcGIS for Desktop Basic
ArcGIS for Desktop StandardArcGIS for Desktop Standard
ArcGIS for Desktop AdvancedArcGIS for Desktop Advanced