<< | Page list | >>
This page reports the different release procedures used across LyX versions
1. Release Procedure for 2.3.0 pre-releases
python development/tools/updatedocs.py
python development/tools/updatelayouts.py
bash development/tools/updatelfuns.sh
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:
check for all critical bugs in translations: ./pocheck.pl -f -i -a *.po
regenerate credits, make lfundoc
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)
2.6 PR
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/
cd $SOMEDIR/lyx-export
./autogen.sh
- configure in some directory
cd $SOMEDIR/build-export
../lyx-export/configure
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
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
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
cd /local/lasgoutt/lyx-export
./autogen.sh
- configure in some directory
cd /local/lasgoutt/build-export
../lyx-export/configure --with-frontend=qt
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