Skip to content
  Kermeta  
 

Procedure for releasing a new K2 version

Document Actions
This document describes the steps for releasing a new Kermeta 2 version.

Change to the new release version (the version must end with an even number)

  1. Check that everything compiles and that most test pass on continuous integration
  2. Verify that the samples and wizard works (fsm, class2rdbms, logo, new project) If possible also try
  3. for all bug and feature done since the previous release, update the history.html in org.kermeta.language.documentation (do not forget to mark the date of the expected release)
  4. Open in eclipse all the required projects (required project are the same as the one in continuous integration)
  5. change the version in all pom.xml to the new release version (the version must end with an even number)
  6. search in *.java if some version are hardcoded there.
  7. search in feature.xml if some version are there. (note : 2.0.99-SNAPSHOT is coded 2.0.99-qualifier in a feature.xml)
  8. locally recompiles all master projects (recommanded orderr: traceability - utils - diagnostic - core - test.helper - emf - kp - library.core - gendoc - ui -
  9. Commit and check that the continuous integration is fully recompiled
  10. download the new studio and check again the samples and wizards
  11. If everything is ok, tag the version, and share the tag
  12. In the continuous integration, for org.kermeta.language.test.test_master, select the last build and mark it for permanent (conserver ce build sans limite de temps)
  13. On kermeta.org web site, archive the current updatesite with the correct version, upload the new updatesite from continuous integration
  14. upload the eclipse packages (from continuous integration) to the kermeta.org web site
  15. upload archives to the forge "files" of the project http://gforge.inria.fr/frs/?group_id=4312 
  16. Notify on the mailing list and in a news on the forge about the availability of the new version

Change back to the new development version

Repeat most of the procedure above with the new development version number (must end with an odd number) (do not need to do the tag)

In gforge.inria.fr, add for each tracker the new target milestone version (or ask Didier), ask Didier to close all bug and feature that are resolved or done.