org.cristalise:cristalise

Cristal-ise is a description-driven software platform originally developed to track the construction of the CMS ECAL detector of the LHC at CERN. This is its core library, known as the kernel, which manages business objects called Items. Items are entirely configured from data, called descriptions, held in other Items. Every change of a state in an Item is a consequence of an execution of an activity in that Item's lifecycle, meaning that Cristal-ise applications are completely traceable, even in their design. It also supports extensive versioning of Item description data, giving the system a high level of flexibility.


Licenses
LGPL-2.0/LGPL-3.0

Documentation

CRISTAL-iSE Build StatusBuild StatusJavadocs

Join the chat at https://gitter.im/cristal-ise/kernel

Description-Driven Framework for No-Code/Low-Code Application Development

Main repository of the CRISTAL-iSE Description-Driven Framework.

CRISTAL-iSE is a description-driven software platform originally developed to track the construction of the CMS ECAL detector of the LHC at CERN. It consists of a core library, known as the kernel, which manages business objects called Items. Items are entirely configured from data, called descriptions, held in other Items. Every change of a state in an Item is a consequence of an execution of an activity in that Item's lifecycle, meaning that CRISTAL-iSE applications are completely traceable, even in their design. It also supports extensive versioning of Item description data, giving the system a high level of flexibility.

Release process

  1. Steps on Github
    1. review issues listed in the github Release
    2. move all open github issues to a new Release (e.g. from 6.0.0 to 6.1.0)
      • make sure all remaining/closed issues have at least the bug/enhancment flags required for the release summary
  2. Steps on the development machine
    1. git checkout develop
    2. git pull -r
    3. git checkout master
    4. git pull -r
    5. git merge develop
    6. resolve all conflicts - there should only one conflict for version number in parent pom
    7. update version tag in the parent pom (e.g. from 6.0-SNAPSHOT to 6.0.0)
    8. mvn -N versions:update-child-modules
    9. mvn clean install - for sanity check, it will be executed in travis anyways
    10. git push
    11. git checkout develop
    12. update version tag in the parent pom (e.g. from 6.0-SNAPSHOT to 6.1-SNAPSHOT)
    13. mvn -N versions:update-child-modules
    14. git push
  3. Step on Github - TBD
    1. tag repo with the release number (e.g. v6.0.0)
    2. update Release with relase summary - check previous Releases for guidance :)
    3. close Release