https://rt-wiki.bestpractical.com/api.php?action=feedcontributions&user=67.183.142.187&feedformat=atomRequest Tracker Wiki - User contributions [en]2024-03-29T12:17:51ZUser contributionsMediaWiki 1.37.2https://rt-wiki.bestpractical.com/index.php?title=ReleaseEngineering&diff=3104ReleaseEngineering2013-08-13T00:47:35Z<p>67.183.142.187: /* • Update and release RT::Client::CLI */ Fix code block with a nowiki tag.</p>
<hr />
<div>=== • Create releng branch ===<br />
<br />
git checkout -b 4.0.14-releng 4.0-trunk<br />
<br />
=== • If necessary, git cherry-pick -x sha1 to pull changes from trunk to branch ===<br />
<br />
=== • Make sure translations are uploaded to Rosetta with enough time to be translated ===<br />
<br />
=== • Import translations ===<br />
<br />
=== • Check if jsmin should be updated on download.bestpractical.com/mirror/ ===<br />
<br />
=== • If 3.8, update configure.ac for the correct version ===<br />
<br />
perl -pi -e s/3.8.HEAD/3.8.18/ configure.ac<br />
git commit -m 'Bump version for 3.8.18' configure.ac<br />
<br />
=== • Tag the release ===<br />
<br />
git tag -sm 'release 4.0.14' rt-4.0.14<br />
<br />
=== • Make the archive ===<br />
<br />
rm -rf autom4te.cache<br />
./configure.ac<br />
make snapshot<br />
<br />
This will build you a snapshot tarball, GPG sign it and give you SHA1 sums. On 3.8, you'll need to sign and generate SHA1 sums yourself:<br />
<br />
gpg --detach-sign rt-3.8.18.tar.gz<br />
sha1sum rt-3.8.18.tar.gz*<br />
<br />
Do not skip reconfiguring, as it ensures you have a fresh build and Makefile. This is especially important if you're releasing 4.0 and 3.8 at the same time from the same clone (i.e. rolling security releases).<br />
<br />
=== • Sanity check tarball and signature ===<br />
<br />
This should include running tests from inside the tarball (with MySQL or Pg), verifying the embedded version (esp. on 3.8), checking that RT starts up on a fresh database, and checking the signature.<br />
<br />
It's nice to let other folks kick the tires as well.<br />
<br />
=== • Upload it ===<br />
<br />
chmod a+rx rt-4.0.14*<br />
scp -rvp rt-4.0.14.tar.gz* download.bestpractical.com:/opt/web/hosted/download.bestpractical.com/html/pub/rt/release/<br />
scp -rvp rt-4.0.14-third-party-source.tar.gz* download.bestpractical.com:/opt/web/hosted/download.bestpractical.com/html/pub/rt/release/third-party-source/<br />
<br />
When making a non-developer release, files live in pub/rt/release and you need to make sure to update the rt.tar.gz symlink:<br />
<br />
ssh download.bestpractical.com ln -svf /opt/web/hosted/download.bestpractical.com/html/pub/rt/release/{rt-4.0.14,rt}.tar.gz<br />
<br />
As soon as you upload a new version into pub/rt/release/, it will be displayed on the corporate site's front page and RT product page.<br />
<br />
Developer releases such as RCs go in pub/rt/devel/.<br />
<br />
=== • Generate docs ===<br />
<br />
From inside a git clone on at least 4.0-trunk:<br />
<br />
devel/tools/rt-static-docs --source rt-X.Y.Z.tar.gz \<br />
--to /path/to/bestpracticalsite/web/static/docs/rt/X.Y.Z<br />
<br />
Commit the changes to the bestpracticalsite repo.<br />
<br />
Diff with previous version docs to check that nothing horrible changed.<br />
<br />
=== • Update release notes in bestpractical.com repo ===<br />
<br />
rsync -av --delete release-notes/[1-9].*.{release,changes} \<br />
bestpracticalsite/web/static/release-notes/rt/<br />
<br />
Commit the changes to the bestpracticalsite repo.<br />
<br />
=== • Pull bestpractical.com live with updates ===<br />
<br />
See checkmarkable.<br />
<br />
=== • Update and release RT::Client::CLI ===<br />
<br />
You may skip this if bin/rt.in is unchanged from the last RT release (and RT::Client::CLI is up to date with the last release).<br />
<br />
cd RT-Client-CLI/<br />
./devel/import-rt<br />
git diff<br />
git commit -am 'Update to 4.0.x'<br />
git push<br />
milla authordeps | cpanm<br />
milla test<br />
vim Changes # add notes to Changes file under <nowiki>{{$NEXT}}</nowiki><br />
milla release # specify correct 4.0.x version<br />
<br />
The last step will increment version numbers, tag, commit, upload to cpan, and push it all to git, with a prompt or two in between.<br />
<br />
=== • Cleanup and preserve history ===<br />
<br />
For stable RT releases after 3.8:<br />
<br />
git checkout 4.0-trunk<br />
git merge --no-ff 4.0.14-releng<br />
<br />
Replace 4.0-trunk with the appropriate trunk branch (e.g. master, 4.2-trunk, etc).<br />
<br />
For RT 3.8:<br />
<br />
git checkout 3.8-trunk<br />
git merge --no-commit --no-ff 3.8.18-releng<br />
git checkout HEAD -- configure.ac<br />
git commit<br />
Note in message that you undid the version bump from the branch</div>67.183.142.187https://rt-wiki.bestpractical.com/index.php?title=ReleaseEngineering&diff=3103ReleaseEngineering2013-08-13T00:02:50Z<p>67.183.142.187: How to release RT::Client::CLI when a new RT version is out</p>
<hr />
<div>=== • Create releng branch ===<br />
<br />
git checkout -b 4.0.14-releng 4.0-trunk<br />
<br />
=== • If necessary, git cherry-pick -x sha1 to pull changes from trunk to branch ===<br />
<br />
=== • Make sure translations are uploaded to Rosetta with enough time to be translated ===<br />
<br />
=== • Import translations ===<br />
<br />
=== • Check if jsmin should be updated on download.bestpractical.com/mirror/ ===<br />
<br />
=== • If 3.8, update configure.ac for the correct version ===<br />
<br />
perl -pi -e s/3.8.HEAD/3.8.18/ configure.ac<br />
git commit -m 'Bump version for 3.8.18' configure.ac<br />
<br />
=== • Tag the release ===<br />
<br />
git tag -sm 'release 4.0.14' rt-4.0.14<br />
<br />
=== • Make the archive ===<br />
<br />
rm -rf autom4te.cache<br />
./configure.ac<br />
make snapshot<br />
<br />
This will build you a snapshot tarball, GPG sign it and give you SHA1 sums. On 3.8, you'll need to sign and generate SHA1 sums yourself:<br />
<br />
gpg --detach-sign rt-3.8.18.tar.gz<br />
sha1sum rt-3.8.18.tar.gz*<br />
<br />
Do not skip reconfiguring, as it ensures you have a fresh build and Makefile. This is especially important if you're releasing 4.0 and 3.8 at the same time from the same clone (i.e. rolling security releases).<br />
<br />
=== • Sanity check tarball and signature ===<br />
<br />
This should include running tests from inside the tarball (with MySQL or Pg), verifying the embedded version (esp. on 3.8), checking that RT starts up on a fresh database, and checking the signature.<br />
<br />
It's nice to let other folks kick the tires as well.<br />
<br />
=== • Upload it ===<br />
<br />
chmod a+rx rt-4.0.14*<br />
scp -rvp rt-4.0.14.tar.gz* download.bestpractical.com:/opt/web/hosted/download.bestpractical.com/html/pub/rt/release/<br />
scp -rvp rt-4.0.14-third-party-source.tar.gz* download.bestpractical.com:/opt/web/hosted/download.bestpractical.com/html/pub/rt/release/third-party-source/<br />
<br />
When making a non-developer release, files live in pub/rt/release and you need to make sure to update the rt.tar.gz symlink:<br />
<br />
ssh download.bestpractical.com ln -svf /opt/web/hosted/download.bestpractical.com/html/pub/rt/release/{rt-4.0.14,rt}.tar.gz<br />
<br />
As soon as you upload a new version into pub/rt/release/, it will be displayed on the corporate site's front page and RT product page.<br />
<br />
Developer releases such as RCs go in pub/rt/devel/.<br />
<br />
=== • Generate docs ===<br />
<br />
From inside a git clone on at least 4.0-trunk:<br />
<br />
devel/tools/rt-static-docs --source rt-X.Y.Z.tar.gz \<br />
--to /path/to/bestpracticalsite/web/static/docs/rt/X.Y.Z<br />
<br />
Commit the changes to the bestpracticalsite repo.<br />
<br />
Diff with previous version docs to check that nothing horrible changed.<br />
<br />
=== • Update release notes in bestpractical.com repo ===<br />
<br />
rsync -av --delete release-notes/[1-9].*.{release,changes} \<br />
bestpracticalsite/web/static/release-notes/rt/<br />
<br />
Commit the changes to the bestpracticalsite repo.<br />
<br />
=== • Pull bestpractical.com live with updates ===<br />
<br />
See checkmarkable.<br />
<br />
=== • Update and release RT::Client::CLI ===<br />
<br />
You may skip this if bin/rt.in is unchanged from the last RT release (and RT::Client::CLI is up to date with the last release).<br />
<br />
cd RT-Client-CLI/<br />
./devel/import-rt<br />
git diff<br />
git commit -am 'Update to 4.0.x'<br />
git push<br />
milla authordeps | cpanm<br />
milla test<br />
vim Changes # add notes to Changes file under {{$NEXT}}<br />
milla release # specify correct 4.0.x version<br />
<br />
The last step will increment version numbers, tag, commit, upload to cpan, and push it all to git, with a prompt or two in between.<br />
<br />
=== • Cleanup and preserve history ===<br />
<br />
For stable RT releases after 3.8:<br />
<br />
git checkout 4.0-trunk<br />
git merge --no-ff 4.0.14-releng<br />
<br />
Replace 4.0-trunk with the appropriate trunk branch (e.g. master, 4.2-trunk, etc).<br />
<br />
For RT 3.8:<br />
<br />
git checkout 3.8-trunk<br />
git merge --no-commit --no-ff 3.8.18-releng<br />
git checkout HEAD -- configure.ac<br />
git commit<br />
Note in message that you undid the version bump from the branch</div>67.183.142.187https://rt-wiki.bestpractical.com/index.php?title=ReleaseEngineering&diff=3102ReleaseEngineering2013-08-12T23:57:21Z<p>67.183.142.187: Flip path names around for docs and release-notes</p>
<hr />
<div>=== • Create releng branch ===<br />
<br />
git checkout -b 4.0.14-releng 4.0-trunk<br />
<br />
=== • If necessary, git cherry-pick -x sha1 to pull changes from trunk to branch ===<br />
<br />
=== • Make sure translations are uploaded to Rosetta with enough time to be translated ===<br />
<br />
=== • Import translations ===<br />
<br />
=== • Check if jsmin should be updated on download.bestpractical.com/mirror/ ===<br />
<br />
=== • If 3.8, update configure.ac for the correct version ===<br />
<br />
perl -pi -e s/3.8.HEAD/3.8.18/ configure.ac<br />
git commit -m 'Bump version for 3.8.18' configure.ac<br />
<br />
=== • Tag the release ===<br />
<br />
git tag -sm 'release 4.0.14' rt-4.0.14<br />
<br />
=== • Make the archive ===<br />
<br />
rm -rf autom4te.cache<br />
./configure.ac<br />
make snapshot<br />
<br />
This will build you a snapshot tarball, GPG sign it and give you SHA1 sums. On 3.8, you'll need to sign and generate SHA1 sums yourself:<br />
<br />
gpg --detach-sign rt-3.8.18.tar.gz<br />
sha1sum rt-3.8.18.tar.gz*<br />
<br />
Do not skip reconfiguring, as it ensures you have a fresh build and Makefile. This is especially important if you're releasing 4.0 and 3.8 at the same time from the same clone (i.e. rolling security releases).<br />
<br />
=== • Sanity check tarball and signature ===<br />
<br />
This should include running tests from inside the tarball (with MySQL or Pg), verifying the embedded version (esp. on 3.8), checking that RT starts up on a fresh database, and checking the signature.<br />
<br />
It's nice to let other folks kick the tires as well.<br />
<br />
=== • Upload it ===<br />
<br />
chmod a+rx rt-4.0.14*<br />
scp -rvp rt-4.0.14.tar.gz* download.bestpractical.com:/opt/web/hosted/download.bestpractical.com/html/pub/rt/release/<br />
scp -rvp rt-4.0.14-third-party-source.tar.gz* download.bestpractical.com:/opt/web/hosted/download.bestpractical.com/html/pub/rt/release/third-party-source/<br />
<br />
When making a non-developer release, files live in pub/rt/release and you need to make sure to update the rt.tar.gz symlink:<br />
<br />
ssh download.bestpractical.com ln -svf /opt/web/hosted/download.bestpractical.com/html/pub/rt/release/{rt-4.0.14,rt}.tar.gz<br />
<br />
As soon as you upload a new version into pub/rt/release/, it will be displayed on the corporate site's front page and RT product page.<br />
<br />
Developer releases such as RCs go in pub/rt/devel/.<br />
<br />
=== • Generate docs ===<br />
<br />
From inside a git clone on at least 4.0-trunk:<br />
<br />
devel/tools/rt-static-docs --source rt-X.Y.Z.tar.gz \<br />
--to /path/to/bestpracticalsite/web/static/docs/rt/X.Y.Z<br />
<br />
Commit the changes to the bestpracticalsite repo.<br />
<br />
Diff with previous version docs to check that nothing horrible changed.<br />
<br />
=== • Update release notes in bestpractical.com repo ===<br />
<br />
rsync -av --delete release-notes/[1-9].*.{release,changes} \<br />
bestpracticalsite/web/static/release-notes/rt/<br />
<br />
Commit the changes to the bestpracticalsite repo.<br />
<br />
=== • Pull bestpractical.com live with updates ===<br />
<br />
See checkmarkable.<br />
<br />
=== • Cleanup and preserve history ===<br />
<br />
For stable RT releases after 3.8:<br />
<br />
git checkout 4.0-trunk<br />
git merge --no-ff 4.0.14-releng<br />
<br />
Replace 4.0-trunk with the appropriate trunk branch (e.g. master, 4.2-trunk, etc).<br />
<br />
For RT 3.8:<br />
<br />
git checkout 3.8-trunk<br />
git merge --no-commit --no-ff 3.8.18-releng<br />
git checkout HEAD -- configure.ac<br />
git commit<br />
Note in message that you undid the version bump from the branch</div>67.183.142.187https://rt-wiki.bestpractical.com/index.php?title=ReleaseEngineering&diff=3101ReleaseEngineering2013-08-12T23:56:32Z<p>67.183.142.187: /* • Generate docs */ Update option name</p>
<hr />
<div>=== • Create releng branch ===<br />
<br />
git checkout -b 4.0.14-releng 4.0-trunk<br />
<br />
=== • If necessary, git cherry-pick -x sha1 to pull changes from trunk to branch ===<br />
<br />
=== • Make sure translations are uploaded to Rosetta with enough time to be translated ===<br />
<br />
=== • Import translations ===<br />
<br />
=== • Check if jsmin should be updated on download.bestpractical.com/mirror/ ===<br />
<br />
=== • If 3.8, update configure.ac for the correct version ===<br />
<br />
perl -pi -e s/3.8.HEAD/3.8.18/ configure.ac<br />
git commit -m 'Bump version for 3.8.18' configure.ac<br />
<br />
=== • Tag the release ===<br />
<br />
git tag -sm 'release 4.0.14' rt-4.0.14<br />
<br />
=== • Make the archive ===<br />
<br />
rm -rf autom4te.cache<br />
./configure.ac<br />
make snapshot<br />
<br />
This will build you a snapshot tarball, GPG sign it and give you SHA1 sums. On 3.8, you'll need to sign and generate SHA1 sums yourself:<br />
<br />
gpg --detach-sign rt-3.8.18.tar.gz<br />
sha1sum rt-3.8.18.tar.gz*<br />
<br />
Do not skip reconfiguring, as it ensures you have a fresh build and Makefile. This is especially important if you're releasing 4.0 and 3.8 at the same time from the same clone (i.e. rolling security releases).<br />
<br />
=== • Sanity check tarball and signature ===<br />
<br />
This should include running tests from inside the tarball (with MySQL or Pg), verifying the embedded version (esp. on 3.8), checking that RT starts up on a fresh database, and checking the signature.<br />
<br />
It's nice to let other folks kick the tires as well.<br />
<br />
=== • Upload it ===<br />
<br />
chmod a+rx rt-4.0.14*<br />
scp -rvp rt-4.0.14.tar.gz* download.bestpractical.com:/opt/web/hosted/download.bestpractical.com/html/pub/rt/release/<br />
scp -rvp rt-4.0.14-third-party-source.tar.gz* download.bestpractical.com:/opt/web/hosted/download.bestpractical.com/html/pub/rt/release/third-party-source/<br />
<br />
When making a non-developer release, files live in pub/rt/release and you need to make sure to update the rt.tar.gz symlink:<br />
<br />
ssh download.bestpractical.com ln -svf /opt/web/hosted/download.bestpractical.com/html/pub/rt/release/{rt-4.0.14,rt}.tar.gz<br />
<br />
As soon as you upload a new version into pub/rt/release/, it will be displayed on the corporate site's front page and RT product page.<br />
<br />
Developer releases such as RCs go in pub/rt/devel/.<br />
<br />
=== • Generate docs ===<br />
<br />
From inside a git clone on at least 4.0-trunk:<br />
<br />
devel/tools/rt-static-docs --source rt-X.Y.Z.tar.gz \<br />
--to /path/to/bestpracticalsite/web/static/rt/docs/X.Y.Z<br />
<br />
Commit the changes to the bestpracticalsite repo.<br />
<br />
Diff with previous version docs to check that nothing horrible changed.<br />
<br />
=== • Update release notes in bestpractical.com repo ===<br />
<br />
rsync -av --delete release-notes/[1-9].*.{release,changes} \<br />
bestpracticalsite/web/static/rt/release-notes/<br />
<br />
Commit the changes to the bestpracticalsite repo.<br />
<br />
=== • Pull bestpractical.com live with updates ===<br />
<br />
See checkmarkable.<br />
<br />
=== • Cleanup and preserve history ===<br />
<br />
For stable RT releases after 3.8:<br />
<br />
git checkout 4.0-trunk<br />
git merge --no-ff 4.0.14-releng<br />
<br />
Replace 4.0-trunk with the appropriate trunk branch (e.g. master, 4.2-trunk, etc).<br />
<br />
For RT 3.8:<br />
<br />
git checkout 3.8-trunk<br />
git merge --no-commit --no-ff 3.8.18-releng<br />
git checkout HEAD -- configure.ac<br />
git commit<br />
Note in message that you undid the version bump from the branch</div>67.183.142.187https://rt-wiki.bestpractical.com/index.php?title=AutomatedTests&diff=302AutomatedTests2013-07-10T17:26:39Z<p>67.183.142.187: Remove old testing info and replace it with a pointer.</p>
<hr />
<div>= <span style="font-size:13px;line-height:21px;">RT has a full test suite for ensuring functionality remains functional between changes. Best Practical smoke tests every commit on a variety of configurations, but it's good practice to run tests yourself if you're making changes to RT when writing a patch you plan to submit (or even one you don't!). The test suite is quite large, and will take some time to run.</span> =<br />
<span style="font-size:13px;line-height:21px;">Instructions for running the tests are in RT's official documentation: </span>http://bestpractical.com/rt/docs/latest/hacking#Test-suite</div>67.183.142.187