Releasing a version of your bundle


When you create an application project using the Maven archetype, your application gets created with bundle version 1.0-SNAPSHOT, and you use the same version for development. You might need to release this bundle and start the development of a new version. For example, you want users to start using your application version 1.0, and you want to start with the development of your application 1.1. 

This section provides you with the information to release a version of your bundle.


To release an initial version

 The following image shows the process to release the initial version of an application:

221_ReleaseVerBundle.png

To export a bundle

Make sure that your definitions are up to date and run the following command to export your bundle:

projects\my-proj> mvn generate-resources -Pexport

To stop the development of bundle version 1.0

Branch or label the sources that you are using in Source Control. Make sure that you do not modify definitions for version 1.0. Run the following command to remove the bundle from your BMC Helix Innovation Studio development instance:

projects\my-proj> mvn com.bmc.arsys:rx-sdk-maven-plugin:undeploy -N

Important

This step is mandatory.

To change a bundle to a released version

  1. (Optional) If you have created or upgraded your application using BMC Helix Innovation Studio SDK release 17.08 or earlier, edit the /package/pom.xml file and make the following changes in the <execution> tag:

    <build>
       <plugins>
           <plugin>
                .
                .
               <executions>
                   <execution>
                       <id>update-def-file</id>
                       <phase>generate-sources</phase>
                       <goals>
                           <goal>update-def-file</goal>
                       </goals>
                   </execution>              
                   <execution>
                       <id>add-manifest</id>
                       <phase>generate-resources</phase>
                       <goals>
                           <goal>add-manifest</goal>
                       </goals>
                   </execution>
                    .
                    .
                    .
               </executions>
           </plugin>
  2. Run the following command to update your POM files:

    projects\my-proj> mvn versions:set -DnewVersion=1.0.0

    The system displays a success message. The following snippet is a sample message:

    [INFO] Updating project com.myco:my-proj
    [INFO] from version 1.0-SNAPSHOT to 1.0.0
    expression: rx-sdk.groupId no value
    expression: rx-sdk.groupId no value
    expression: rx-sdk.groupId no value
    [INFO]
    [INFO] ------------------------------------------------------------------------
    [INFO] Reactor Summary:
    [INFO]
    [INFO] my-proj-all ....................................... SUCCESS [ 54.270 s]
    [INFO] My Project ........................................ SKIPPED
    [INFO] my-proj-package ................................... SKIPPED
    [INFO] ------------------------------------------------------------------------
    [INFO] BUILD SUCCESS
    [INFO] ------------------------------------------------------------------------

The version gets created in the following format:

<major version>.<minor version>.<incremental version>-<qualifier>

For example, 17.11.017.11.0-SNAPSHOT1.0-SNAPSHOT1.0.0.RELEASE.

To compile a deployment package

Make sure that all the sources, and the renamed definition files, are correctly packaged together in the deployment zip file and run the following command:

projects\my-proj> mvn clean install

The compiled deployment package is present at projects\my-proj\package\target\com.myco.my-proj-1.0.zip. The com.myco.my-proj-1.0.zip file contains the following files:

  • db
    • record
      • <record-definition-name1>.def
      • <record-definition-name2>.def
      • <record-definition-name3>.def
      • <record-definition-name3>.options
      • <record-definition-name3>.data
      • <record-definition-name3>.delete
    • process
      • <process-definition-name1>.def
      • <process-definition-name2>.def
    • rule
      • <rule-definition-name>.def
    • association
    • view
      • <view-definition-name>.def
    • named-list
      • <named-list-definition-name1>.def
      • <named-list-definition-name2>.def
    • localized-string
      • <localized-strings.def>
    • configuration.data
    • role.data
  • code <jar file>
  • manifest file

To complete the release process

Make the package projects\my-proj\package\target\com.myco.mypackage.my-proj-1.0.zip available to administrators. The package is then made available to QA for black-box or integration testing, or pre-production shared system.

Guidelines for creating a new version of an application

When you upgrade your application to a new version, make sure that the modifications made to the new version of your application do not affect the functionalities of the existing application version. The following table lists the guidelines to create a new version of an application:

Guideline

Description 

You want to add new functionality that is implemented by using new definitions.

To create new functionality for your application, create the following new definitions and new code modules:

  • Record definitions and extended Foundation data definitions
  • Association definitions
  • View definitions and view components
  • Process definitions
  • Java-based services, data page queries, commands, and REST resources
  • Named list definitions
  • Specific rule definitions
  • Roles
  • Configuration settings
  • Bundle data

Your application code changes must be backward compatible.

View components

  • Add new properties that are not mandatory.
  • Do not change any JavaScript method that is user-facing.
  • Provide opt-in consumption of the UI changes by adding configuration settings in your application.

Java-based services

  • Do not delete the existing interfaces.
  • Do not add new mandatory parameters.
  • Do not modify a service that can affect the application configuration.

Your existing noncustomizable definitions changes must be backward compatible.

Record definitions

  • Do not delete record definitions or fields.
  • Do not change the field ID values.

View definitions

  • Add parameters.
  • Add, modify, or delete view components.

Process definitions

  • Before you delete process activities, make sure that the activities are not used in process instances.
  • Before you modify the properties of process activity, make sure that they are not dependent on other definitions like rule definitions and process definitions.
  • Do not delete a User Task or a Receive Task.
  • If you add new elements, your process logic must consider the activity results as optional.

Rule definitions

  • Do not add new rule definitions
  • Do not modify the existing rule definitions that directly interact with business logic.
  • You can modify the rule definitions that are independent of other definitions and do not affect application data and definitions.

Do not modify the existing definitions and data that can be customized at all times.

Named list definitions

  • Do not delete or modify the existing named list definitions.
  • You can modify specific, named list definitions that do not affect the users.

Association definitions, Roles, Configuration settings

Do not modify or delete the existing association definitions, roles, or configuration settings.

Bundle data

Before you delete bundle data, make sure that the bundle data is independent of the customizable definitions.

To release a new version

  1. Run the following command to update your POM files:

    projects\my-proj> mvn versions:set -DnewVersion=1.1.0-SNAPSHOT

    The new version is created in the following format:

    <major version>.<minor version>.<incremental version>-<qualifier>

    For example: 17.11.017.11.0-SNAPSHOT1.0-SNAPSHOT1.0.0.RELEASE

    Important

    BMC Helix Innovation Studio uses <major version>, <minor version>, and <incremental version> parameters for versioning an application.

    • If you change the <major version> or <minor version> parameter in an application version, a new version of your application is created. 
    • If you change the <incremental version> parameter in an application version, the existing version of your application is updated.
  2. Run the following command to deploy the new version:

    projects\my-proj> mvn clean install -Pdeploy

By default, you can only have two versions of an application on a system. If you deploy a third version, the system generates the following error message:

9164: Maximum number of allowed versions exceeded.

BMC SaaS Operations must undeploy the oldest version.

Warning

If the latest version is undeployed, all versions of the application are undeployed from the system. 



 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*