wiki:en/howto_release
developer.jelix.org is not used any more and exists only for history. Post new tickets on the Github account.
developer.jelix.org n'est plus utilisée, et existe uniquement pour son historique. Postez les nouveaux tickets sur le compte github.

Version 11 (modified by laurentj, 10 years ago) (diff)

new publish_release.sh script on the server

Releasing a new version of Jelix

What should have been done to release a new version of jelix..

Maintenance release or new alpha/beta

Instruction to release a new version for which we don't need to create a new branch:

  • new version which fixes bugs for a specific stable branch
  • an alpha or beta version from the trunk
  • check if this files are updated:
    • README
    • lib/jelix/CREDITS
    • lib/jelix/INSTALL
    • lib/jelix-modules/CREDITS
  • update the version number in these files to reflect the new version
    • lib/jelix/VERSION
    • lib/jelix/CHANGELOG
    • testapp/VERSION
  • update changelogs in the web site: http://jelix.org/articles/en/changelog
    • a page should be dedicated to the release, with the list of improvements and bug fixed
    • this page should be listed on the changelog page
    • don't forget similar pages in other languages
    • create a new page for the next minor version
  • add a tag in the hg repository : RELEASE_JELIX_X_Y_Z where X_Y_Z is the version number. ex: 1_1_3, 1_2_BETA1
  • create packages localy with build/buildjelix.php and build/buildapp.php and test them
  • on the server, run
    • install/publish_release.sh $BRANCH_VERSION $TAG_NAME $VERSION where:
      • $BRANCH_VERSION is the name of the 'branch': 1.0.x, 1.1.x, 1.2.x
      • $TAG_NAME is the tag in the hg repository, for the release (RELEASE_JELIX_1_0_11 for example)
      • $VERSION the version number of the release (1.0.11 for example)
    • it will create package and upload them on jelix.org and berlios.de
  • build and update the API documentation on the web site, by running this command line on the server
    • install/build_release_doc $BRANCH_VERSION $TAG_NAME $VERSION where:
      • $BRANCH_VERSION is the name of the 'branch': 1.0.x, 1.1.x, 1.2.x or trunk
      • $TAG_NAME is the tag in the hg repository, for the release (RELEASE_JELIX_1_0_11 for example)
      • $VERSION the version number of the release (1.0.11 for example)
  • optional: build and publish the manual, by running this command line on the server
    • install/build_release_manual $LANG $PAGE_ID $VERSION where:
      • $LANG is the language code : "en" or "fr"
      • $PAGE_ID is the id of the first page of the manual. ex: en:manual-1.0
      • $VERSION is the version of the release (1.0.11 for example)
  • update files pages on berlios.de
  • update home page of the web site (through the svn repo of the web site)
  • update the download page on the web site
  • update the html page on jelix.org/references/ to add links to the new api documentation (need access to the web site repository)
  • publish a news on jelix.org/news/
  • modify this files to reflect the next future version, with a "pre" suffix
    • lib/jelix/VERSION
    • lib/jelix/CHANGELOG
    • testapp/VERSION
  • on the bug tracker
    • close the corresponding roadmap
    • create a roadmap for the next version
    • add the released version in the list of versions

New major release

Instruction to release a new major version of Jelix, from the trunk repository. A new branch should be created for futur minor versions.

  • check if this files are updated:
    • README
    • lib/jelix/CREDITS
    • lib/jelix/INSTALL
    • lib/jelix-modules/CREDITS
  • update the version number in these files to reflect the new version
    • lib/jelix/VERSION
    • lib/jelix/CHANGELOG
    • testapp/VERSION
  • update changelogs in the web site: http://jelix.org/articles/en/changelog
    • a page should be dedicated to the release, with the list of improvements and bug fixed
    • this page should be listed on the changelog page
    • don't forget similar pages in other languages
    • create a new page for the next minor version for this new branch, and one for the next major version
  • add a tag in the hg repository : RELEASE_JELIX_X_Y_0 where X_Y_0 is the version number. ex: 1_3_0
  • create packages with build/buildjelix.php and build/buildapp.php to test them
  • on the server, run
    • install/publish_release.sh $BRANCH_VERSION $TAG_NAME $VERSION where:
      • $BRANCH_VERSION is the name of the 'branch': 1.0.x, 1.1.x, 1.2.x
      • $TAG_NAME is the tag in the hg repository, for the release (RELEASE_JELIX_1_0_11 for example)
      • $VERSION the version number of the release (1.0.11 for example)
    • it will create package and upload them on jelix.org and berlios.de
  • build and update the API documentation on the web site, by running this command line on the server
    • install/build_release_doc $BRANCH_VERSION $TAG_NAME $VERSION where:
      • $BRANCH_VERSION is the name of the 'branch': 1.0.x, 1.1.x, 1.2.x or trunk
      • $TAG_NAME is the tag in the hg repository, for the release (RELEASE_JELIX_1_0_11 for example)
      • $VERSION the version number of the release (1.0.11 for example)
  • optional: build and publish the manual, by running this command line on the server
    • install/build_release_manual $LANG $PAGE_ID $VERSION where:
      • $LANG is the language code : "en" or "fr"
      • $PAGE_ID is the id of the first page of the manual. ex: en:manual-1.0
      • $VERSION is the version of the release (1.0.11 for example)
  • update files pages on berlios.de
  • update home page of the web site (through the svn repo of the web site)
  • update the download page on the web site
  • update the html page on jelix.org/references/ to add links to the new api documentation (need access to the web site repository)
  • publish a news on jelix.org/news/
  • create a new branch, by creating a clone of the trunk repository jelix-y.z.x
  • in the new branch, modify this files to reflect the next minor future version, with a "pre" suffix
    • lib/jelix/VERSION
    • lib/jelix/CHANGELOG
    • testapp/VERSION
  • in the trunk, modify this files to reflect the next major future version, with a "pre" suffix
    • lib/jelix/VERSION
    • lib/jelix/CHANGELOG
    • testapp/VERSION
  • on the bug tracker
    • close the corresponding roadmap
    • create a roadmap for the next major version and the next minor version
    • add the released version in the list of versions