Hi All,
I thought that it would be best to build RT from the git repository for convenience and the ability to rebase our customisations onto new versions when they are released.
However when I clone the Github repository, checkout the rt-4.0.7 tag, and build from there I end up with RT “3.9-EXPORTED” instead of “4.0.7”.
Can anyone explain why this is the case?
It also appears that the tar files available from downloads.bestpratical.com differ significantly than those generated directly through Github, the Github file shares the same “3.9-EXPORTED” version while the best practical file is 4.0.7.
Thanks,
John Kelsh
Applications & Systems Administrator
NetSpot Pty. Ltd. ~ 183 Melbourne St. North Adelaide SA 5006
Ph: 08 8361 6800 | Fax: 08 8361 6811
Email: john.kelsh@netspot.com.au | Web: http://www.netspot.com.au
I thought that it would be best to build RT from the git repository
for convenience and the ability to rebase our customisations onto new
versions when they are released.
However when I clone the Github repository, checkout the rt-4.0.7
tag, and build from there I end up with RT “3.9-EXPORTED” instead of
“4.0.7”.
Can anyone explain why this is the case?
rm -rf autom4te.cache/ should help.
It also appears that the tar files available from
downloads.bestpratical.com differ significantly than those generated
directly through Github, the Github file shares the same
“3.9-EXPORTED” version while the best practical file is 4.0.7.
Github’s tarballs are exports of git tags, no more, but that’s not our
release process and they aren’t actual releases. Unfortunately Github
doesn’t let you disable the Download section, which is terribly
frustrating. Don’t use the Github tarballs.
It also appears that the tar files available from
downloads.bestpratical.com differ significantly than those generated
directly through Github, the Github file shares the same
“3.9-EXPORTED” version while the best practical file is 4.0.7.
Github’s tarballs are exports of git tags, no more, but that’s not our
release process and they aren’t actual releases. Unfortunately Github
doesn’t let you disable the Download section, which is terribly
frustrating. Don’t use the Github tarballs.
Ok, so if tags don’t relate to releases, how can I obtain a specific release from github?
Currently I do this:
git clone git://github.com/bestpractical/rt.git /opt/rt4
cd /opt/rt4
git checkout rt-4.0.7
./configure.ac
rm -rf autom4te.cache
./configure --enable-layout=inplace --enable-gd --with-db-type=Pg
make testdeps
make install
apachectl restart
Any advice appreciated.
Thanks,
John Kelsh
Applications & Systems Administrator
NetSpot Pty. Ltd. ~ 183 Melbourne St. North Adelaide SA 5006
Ph: 08 8361 6800 | Fax: 08 8361 6811
Email: john.kelsh@netspot.com.au | Web: http://www.netspot.com.au
Github’s tarballs are exports of git tags, no more, but that’s not our
release process and they aren’t actual releases. Unfortunately Github
doesn’t let you disable the Download section, which is terribly
frustrating. Don’t use the Github tarballs.
Ok, so if tags don’t relate to releases, how can I obtain a specific release from github?
Tags do relate to releases, but not quite everything in a release is
in git. Some of it is still generated at release-time and only included
in the official tarballs (obviously github can’t include it!). Checking
out the git tag will still get you the code for that release, which you
can run (see below).
Currently I do this:
git clone git://github.com/bestpractical/rt.git /opt/rt4
cd /opt/rt4
git checkout rt-4.0.7
./configure.ac
rm -rf autom4te.cache
./configure --enable-layout=inplace --enable-gd --with-db-type=Pg
make testdeps
make install
apachectl restart
Any advice appreciated.
That looks mostly fine. An important change I’d recommend is checking
out rt.git somewhere other than /opt/rt4 (/usr/local/src/rt maybe) and
installing into /opt/rt4 instead of using the inplace layout. This lets
you track the official rt.git repo separately from your deployment, as
well as keeping your specific deployment (configuration, etc) in it’s
own local git repo.
What I describe is more or less how we manage our RT installations at
Best Practical.