/
Versioning "develop" and "master"

Versioning "develop" and "master"

2017-Mar-27

  1. Overview

    Documentation on basic versioning strategy (as of March 2017)

    Managing Versions

    The develop branch of the git repository is where features are pushed and deployed to UAT for testing.  

    The develop branch should always be one minor version ahead of master.  For example

    • master = 1.3.1

    • develop = 1.3.2-SNAPSHOT

    When it comes time to deploy features to PROD, the master branch needs to be updated/synchronized before that happens.

    The basic process is this:

    1. Pull latest changes for the repository.

    2. Ensure the project is set to the "develop" branch.

    3. Use "mvn versions:set" to change the versions of the develop branch to the next release version (e.g. 1.3.2)

       

      cd /path/to/ihtsdo-refset-management-service mvn versions:set ... when prompted, type in the next version (e.g. 1.3.2) cd parent/ mvn versions:set ... when prompted type in the next version (e.g. 1.3.2)

    4. Commit the "develop" branch changes (but not need to push)

    5. Switch to the "master" branch

    6. Merge changes from "develop" to "master"

    7. Push the "master" branch (it now has the next release version) 

    8. Switch back to the "develop" branch.

    9. Use "mvn versions:set" to change the versions to the next develop version

       

      cd /path/to/ihtsdo-refset-management-service mvn versions:set ... when prompted, type in the next version (e.g. 1.3.3-SNAPSHOT) cd parent/ mvn versions:set ... when prompted type in the next version (e.g. 1.3.3-SNAPSHOT)

    10. Commit the "develop" branch and push this change

    11. Redeploy UAT to reflect the next dev version



    NOTE: you may notice the complexity of running versions:set twice.  This is because of the split nature of the parent and aggregator modules.  It is recommended in the future that parent project be merged into the aggregator and removed.  Thant involves:

    1. Moving the dependencyManagement section from parent/pom.xml to pom.xml

    2. Moving the pluginManagement section from parent/pom.xml to pom.xml

    3. Removing "parent" from the modules list in pom.xml

    4. Updating pom.xml to remove the "<parent>" section at the top (it is now the parent)

    5. Also change pom.xml description to indicate that it is both parent and aggregator

      1. in particular, change the artifactId to be "...-parent" instead of "...-aggregator" (this is for the next part)

    6. update all other pom.xml files in submodules to change the relativePath to the parent module 

      1. from "../parent" to ".." 

      2. OR from "../../parent" to "../.."

    References/Links

    • n/a

Copyright © 2025, SNOMED International