Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin

This info is for Lenya committers who need to prepare a new release of Lenya. Most steps are the same as for Cocoon. Some additional notes are below.

See also

Release Schedule

Users are encouraged to test the stable branch continuously and report problems.

  1. Wiki Markup
    \[OPTIONAL\] Vote on making release, if there is no mid or long term release plan with already established release dates. 2. *Announce beginning of release/freeze* along this schedule 7 days in advance including the actual freeze date.  3. *Freeze source branch* e.g. lenya/branches/BRANCH_1_2_X and *send a freezed reminder* to dev mailing list. Developers watch commits mailing list for commits to freezed branch, and inspect diffs to determine risk level. Risky changes are alerted on the developer list and rolled back, unless a vote passes to keep the risky change. 4. *Start testing* the freezed code along the [test plan|TestCases]. A *test sprint on IRC* is good for concentrated testing. _The tests should be made on basis of a completely build Lenya binary distribution on Windows and Linux._ It would be great, if we could make test installations available for the public and during the test sprint. 5. *New bugs* found during 4 MUST be recorded in bugzilla. Bugs marked as CRITICAL or BLOCKER MUST be fixed before the release. 6. Start at 4 again 7. If tests are ok, *vote on to release* immediately; on a positive vote summary, *create a tag branch*; svn copy from a branch to a tag e.g. lenya/branches/BRANCH_1_2_X to lenya/tags/RELEASE_1_2_1, lock down the tagged version e.g. lenya/tags/RELEASE_1_2_1, then *release* (see *Platform independent notes* below). 8. Edit the *Downloads* links on the web site with links to the new release files.  (Currently that's [index.xml|] and [docs/1_2_x/installation/index.xml|].) 9. Publish a [ProjectReleaseAnnouncement] to appropriate places:

10. Update the Lenya DOAP file ( with the version and date of this new release.


  • Try to find a day for the test sprint, where lots of devs are present.

Platform independent notes

  • compile a pristine cocoon with the local properties from lenya
  • Set property version in file src/targets/properties-build.xml to the appropriate Lenya version
  • regenerate INSTALL-src.txt and INSTALL-bin.txt with the appropriate XSLT
  • build all distribution archives, except the windows installer .exe, with ./|build dist in the Lenya source root directory. You will find the distribution archives under LENYA_SRC_DIR/dist. The dist target will also build, in case of the binary distribution, and package the editors BXE and Kupu.
  • sign the release archives with your PGP/GPG key. See instructions below.
  • Upload the release to minotaur.a.o:/x1/www/

PGP/GPG signatures on releases

  • If not yet done add your key to the KEYS file. Follow the instruction at the top of that file.
  • Export you public key with gpg -a -export Big Lumber; Key management made easy] > .pgpkey and place the file .pgpkey on minotaur.a.o in your home directory. You also would sign up at [ to easily coordinate and manage signatures for your key.
  • Update the KEYS file at minotaur.a.o:/x1/www/ from Lenya SVN.

ASF signing Resources

Windows installer

  • Up to Lenya 1.2.x edit file lenya.nsi and replace all version numbers appropriate
  • compile lenya.nsi with the NSIS compiler (use the LZMA compressor for the smallest binaries)
  • Sign the .exe file with your PGP/GPG public key.