Version Policy

Version policy

Expanders Versioning


e.g. 3.1.5 or


Master Branch

Master branch should focus primarily on the development of the individual expanders. Any and all changes to the metaexpansion or infrastructure should be handled with care (as was customary until now).

This branch is updated and versioned without any regard or knowledge of the next branch.

Next Branch

Next branch should contain most (all) development of the expansion infrastructure, changes in API, improvements, etc.

Development of expanders themselves should be limited, typically only migration of an expander to a new infrastructure.

Deadlock Avoidance

To ensure that we can always run expanders and be able to regenerate even broken builds, neither default nor next can dependent on elements(io/shared) version that it expanded itself.

Releasing Cycle

Once a stable point of next was reached, the following steps must be taken:

  1. expand elements-ioxml with default
  2. push default Expanders of version vExp so Jenkins can produced shared and IO layers of version vShared
  3. after Jenkins finishes, restart test PR for elements-ioxml jenkins and run the project
  4. merge default into next
  5. update next to depend on vShared
  6. update next version to vExp+1
  7. increase shared and IO versions that will be produced by next to vShared+1
    • this is to ensure that next doesn’t override its dependency
  8. merge next into default
  9. increment next to vExp+1
  10. cycle complete

Fixing Issues

When an issue is discovered in the dependencies of vExp+1, we can use vExp to introduce the fix and regenerate vShared.