• Browse GIT
• View
• Edit
• Upload
• History
• Print

ReleaseProcedure

This page reports the different release procedures used across LyX versions

1.  Release Procedure for 2.3.0 pre-releases

• update docs

python development/tools/updatedocs.py

• update layouts

python development/tools/updatelayouts.py

• update LFUNs

bash development/tools/updatelfuns.sh

• remerge strings

make update-po && make update-gmo

• put release name and date in

configure.ac ./autogen.sh && ./configure --enable-build-type=pre && make lyxdist

• sign both tar balls
• change configure.ac back to devel

2.  Release Procedure for 2.0.0 pre-releases

This procedure is heavily based on the previous versions.

At some final stage:

2.1  In the source:

• update version and date in configure.ac (the last file to commit)
• update ANNOUNCE by editing the top of the file and pasting status.20x into the bottom
• When this is OK, copy the start of the announcement to NEWS
• Update the RELEASE-NOTES file, in so far as that makes sense
• check the distribution (in the build directory); (you should check monolithic builds too)

              make distcheck

• check if any files has been updated (po files in particular)
• commit changes
• make a distribution

              rm -rf /tmp-path/lyx-export
              svn export . /tmp-path/lyx-export
              cd /tmp-path/lyx-export
              ./autogen.sh && ./configure --enable-build-type=pre && make lyxdist  #final release should have --enable-build-type=rel

• tag release (as lyx-2_x_ybeta2, where beta2 is an example that should be replaced by the right version)

              svn cp svn://svn.lyx.org/lyx/lyx-devel/trunk svn://svn.lyx.org/lyx/lyx-devel/tags/lyx_2_0_0beta2 -m'Tag release lyx-2_0_0beta2'

• change the version back to svn and commit.

2.2  On the ftp site

• create gpg signature: gpg -b lyx-2.0.0alpha5.tar.xz
• update dist to ftp.lyx.org/pub/lyx/stable/
• accepted binaries should have pgp signatures as well

2.3  Sending mail

• send annoucement to lyx-announce, lyx-devel and lyx-users with Reply-to lyx-users. Add lwn@lwn.net in bcc. (in case of alpha post only to lyx-devel and lyx-users, lwn@lwn.net just for major events like rc1, full release)

2.4  Web site www-user (not for alphas)

• add announcement as announcement/1_x_y.txt
• update news.inc
• update last version number in index.php
• cd misc/rss && make . If output is reasonable (usually two lines of diff) the svn ci just updates RSS feeds.

2.5  Web site (update pages)

• Update http://wiki.lyx.org/LyX/ReleaseNotes
• Update download links in: http://www.lyx.org/Download

2.6  PR

• See ReleasePR

3.  Release Procedure for maintenance releases (2.3.x [x>0])

3.1  In the source:

• update version and date in configure.ac
• update ANNOUNCE; in particular, copy status.22x to the end of that file
• when this is OK, copy the start of the announcement to NEWS
• update RELEASE-NOTES insofar as that makes sense
• check if any files have been updated (po files in particular)
• remerge po files
• commit changes
• create the distribution
  • these steps can be done by running the development/tools/lyx-build script.
  • export a clean tree

              rm -rf $SOMEDIR/lyx-export
              git checkout-index -a -f --prefix=$SOMEDIR/lyx-export/

• run ./autogen.sh

              cd $SOMEDIR/lyx-export
              ./autogen.sh

• configure in some directory

              cd $SOMEDIR/build-export
              ../lyx-export/configure

• make a distribution.

              make dist
              make lyxdist

• create a patch between distribution and previous

              diff -urN -x .svn -x version.cpp lyx-2.x.(y-1) lyx-2.x.y > patch

• read the patch and check that it makes sense
• update patch-preamble (a private file) and add ANNOUNCE to it
• create the final patch: cat patch-preamble patch > patch-2.x.y
• create gz and xz versions of the patch:

              gzip -c patch-2.x.y > patch-2.x.y.gz
              xz -zc patch-2.x.y > patch-2.x.y.xz

• create OpenGPG signatures of distribution tarballs and patches:

              gpg -b patch-2.x.y.gz
              gpg -b patch-2.x.y.xz

• build a binary from the tarball to make sure it compiles properly.

• put the release candidate somewhere people can test it on different platforms. do not proceed until there is confirmation that it is ok.
• tag release as lyx-2_x_y

              cd <gitdir>
              git tag -a 2.0.y -m'This is LyX 2.x.y'
              git push --tags

• Note that it wouldn't be a bad idea to sign these tags with the LyX key. To do that, first tell git about the LyX key:

              git config --global user.signingkey 0x<key-id>

• You can get the key-id from gpg --list-keys. It's an eight digit hexadecimal number.
• Now tag as follows:

              git tag -s 2.x.y -m'This is LyX 2.x.y'

• change the version back in configure.ac to svn and commit.

3.2  On the ftp site

• Upload gz and xz files, patches, and GPG signatures to ftp.lyx.org/pub/lyx/stable/lyx-2.3.x
• Create a softlink lyx-2.3.x.tar.gz pointing at the latest version
• Check the access rights by attempting to download the files
• Create directory ftp.lyx.org/pub/lyx/bin/2.3.N for new version
• Upload the binaries to ftp.lyx.org/pub/lyx/bin/lyx-2.3.N

3.3  Sending mail

• It's a good idea to wait 12-24 hours after uploading everything to the ftp site before proceeding to this next step, so that the mirrors will have time to synchronize.
• Send an annoucement to lyx-announce, lyx-devel and lyx-users with Reply-to lyx-users. It's sufficient to paste the ANNOUNCE file into an email. Add lwn@lwn.net in bcc. The subject should be "LyX 2.3.x Released".

3.4  Web site/www-user

• Add announcement as announcement/2_x_y.txt
• Update farm/cookbook/LyX/news.inc. Remember to include a link to the announcement.
• Update translation status in farm/cookbook/LyX/i18n.inc (generated by make i18n.inc in po/ directory).
• In case of initial major release change the variable lyx_branch in po/postats.py from empty string to branch tag, e.g. for 2.5.0 you should set lyx_branch="2.5.x" and leave it that way for the rest of 2.5.x cycle.
• Run make in misc/rss to update RSS feed
• Commit changes in www-user
• Adapt version numbers on download page
  • Note that this just means changing a single variable, versiontext, so long as the binaries follow the same naming pattern as in the previous version (which they presumably should).
• Adapt roadmap

3.5  Wiki

• Update ReleaseNotes

3.6  Trac

• Add new version
• Add new milestone
• Resolve bugs whose status is "Fixed" or "Fixed in stable" as FIXED (resolution) and CLOSED (status).
  • This can all be done with the BatchModifyPlugin: Add the Status and Resolution fields, and set them accordingly. Note that you can uncheck the "Send Email Notifications" and "Modify ticket changetime", which will probably be a good idea for most of these changes.
• Set target milestone for "Fixed in stable bugs to the devel version.
• Close current milestone, increase milestone of remaining open bugs.
  • This is done by going to the Roadmap (it's on the navigation bar above), clicking on the milestone in question, and then choosing "Edit Milestone".
• Update the version of the "next maintenance release" on the bug tracker home page.
• Examine the remaining fixedintrunk bugs to see which should be committed early in the new cycle.

Devel

3.7  PR

• See ReleasePR

Category LyX

4.  Release Procedure for 1.4.x (x>0) releases

From post by Jean-Marc 2006-11-14

Here is what I do these days for 1.4 releases.

In the source:

• update version and date in configure.ac
• update version in po/postats.sh
• update ANNOUNCE; when this is OK, copy the start of the announcement to NEWS
• export to some directory

              rm -rf /local/lasgoutt/lyx-export
              svn export . /local/lasgoutt/lyx-export

• run ./autogen.sh

              cd /local/lasgoutt/lyx-export
              ./autogen.sh

• configure in some directory

              cd /local/lasgoutt/build-export
              ../lyx-export/configure --with-frontend=qt

• make a distribution.

              make dist

• create a patch between distribution and previous

              diff -urN -x .svn -x version.C lyx-1.x.(y-1) lyx-1.x.y >patch

• read the patch and check that it makes sense
• update 1.x.y.desc and add ANNOUNCE to it
• create the patch: cat 1.x.y.desc patch >patch-1.x.y
• create bz2 versions of distribution and patch
• tag release as lyx-1_x_y

              cd src/lyx/1.4.x
              svn cp . svn+ssh://lasgouttes@svn.lyx.org/lyx/lyx-devel/tags/lyx-1_x_y

On the ftp site

• update dist and patch to ftp.lyx.org/pub/lyx/stable/
• create directory ftp.lyx.org/pub/lyx/bin/1.x.y

Sending mail

• send annoucement to lyx-announce, lyx-devel and lyx-users with Reply-to lyx-users. Add lwn@lwn.net in bcc.

Web site www-user

• add announcement as announcement/1_x_y.txt
• update news.inc
• update last version number in index.php

5.  Release Procedure for 1.4.0 pre-releases

Copied from a post by Lars 2006-01-29:

• Start with a clean tree
• Change the version in configure.ac
• ./autogen.sh && ./configure --with-frontend='qt xforms gtk'
• make distdir
• Check if any files has been updated (po files in particular)
• Commit the changed files ('remerge')
• make DISTCHECK_CONFIGURE_FLAGS='--with-frontend="qt xforms gtk"' distcheck
• Commit the configure.ac change
• Tag the lyx-devel module (cvs rtag lyx-1_4_0pre4 lyx-devel)
• Change the version back to cvs and commit.
• Export the pre4 tag (cvs export -r lyx-1_4_0pre4 -d lyx-1.4.0pre4 lyx-devel)
• ./autogen.sh && ./configure --with-frontend='qt xforms gtk'
• make DISTCHECK_CONFIGURE_FLAGS='--with-frontend="qt xforms gtk"' distcheck
• Copy the resulting packages to ftp.devel.lyx.org

Category: Devel, Release