How release tarballs are created

[Brad Smith]

For future releases could you please consider naming the release tarball as x265-X.Y.tar.bz2 (.e.g. x265-1.5.tar.bz2) and have the source within the tarball within a dir of the same naming format (.e.g x265-1.5/)? The tarball without a name on it is kinda ugly and doesn't make it obvious what it is when in a dist files directory with other projects. 1.5.tar.bz2, but 1.5 of what? and the dir within the tarball follows more common naming conventions and makes it easier for various tools / build infrastructure that build packages.

[djcj]

Adding the release version to source/cmake/version.cmake would be great too.

--- a/source/cmake/version.cmake
+++ b/source/cmake/version.cmake
@@ -6,8 +6,8 @@
 find_package(Git QUIET) # present in 2.8.8

 # defaults, in case everything below fails
-set(X265_VERSION "unknown")
-set(X265_LATEST_TAG "0.0")
+set(X265_VERSION "1.4")
+set(X265_LATEST_TAG "1.4")
 set(X265_TAG_DISTANCE "0")

 if(EXISTS ${CMAKE_SOURCE_DIR}/../.hg_archival.txt)

[Steve Borho]

We don't make any tarballs available. Our only source release mechanism is this Mercurial repository. We generally only support cloning. Bitbucket does have an automated mechanism for generating tarballs for specific revisions; but we have no control over how that works. If you download one of these tarballs, it should have an .hg-archive.txt file in it describing the revision and tag (if applicable). The cmake script will use the data in this file if it is present. If you are getting tarballs somewhere else, and they don't have this file.. eh, stop getting them that way.

[djcj]

There is no .hg-archive.txt file. Only a .hg folder and two textfiles .hgignore and .hgtags.

edit:

You can use these shell scripts to create release tarballs:

#!/bin/sh
# stable release

rm -rf x265-source
hg clone https://bitbucket.org/multicoreware/x265 x265-source
cd x265-source && hg checkout stable

VERSION=$(hg parents --template '{latesttag}')

sed -i "s/set(X265_VERSION \"unknown\")/set(X265_VERSION \"${VERSION}\")/;" source/cmake/version.cmake
sed -i "s/set(X265_LATEST_TAG \"0.0\")/set(X265_LATEST_TAG \"${VERSION}\")/;" source/cmake/version.cmake
rm -rf .hg .hgignore .hgtags

cd ..
mv x265-source x265-${VERSION}
find x265-${VERSION} -type d -empty -delete

tar -cJf "x265_${VERSION}.orig.tar.xz" "x265-${VERSION}/"

#!/bin/sh
# snapshot

rm -rf x265-source
hg clone https://bitbucket.org/multicoreware/x265 x265-source
cd x265-source

LT=$(hg parents --template '{latesttag}')
LTD=$(hg parents --template '{latesttagdistance}')
NODE=$(hg parents --template '{node|short}')
VERSION=${LT}+${LTD}+hg${NODE}

sed -i "s/set(X265_VERSION \"unknown\")/set(X265_VERSION \"${VERSION}\")/;" source/cmake/version.cmake
sed -i "s/set(X265_LATEST_TAG \"0.0\")/set(X265_LATEST_TAG \"${LT}\")/;" source/cmake/version.cmake
sed -i "s/set(X265_TAG_DISTANCE \"0\")/set(X265_TAG_DISTANCE \"${LTD}\")/;" source/cmake/version.cmake
rm -rf .hg .hgignore .hgtags

cd ..
mv x265-source x265-${VERSION}
find x265-${VERSION} -type d -empty -delete

tar -cJf "x265_${VERSION}.orig.tar.xz" "x265-${VERSION}/"

[Steve Borho]

/me curses bitbucket for being so obtuse

[Steve Borho]

is the attached tar-ball acceptable? it was created by:

hg archive -r 1.4 -t tgz x265_1.4.tar.gz

If this is ok, I'll back-fill tar-balls for the previous releases

[Steve Borho]

I tested this myself and found a problem; cmake is finding version 1.4 and reporting 1.4, but is still passing the string "unknown" to version.cpp so the binary is not tagged properly. I'll look into this and fix it, but it means the older tags will be similarly broken so this fix will only work with version 1.5 and later

[Steve Borho]

cmake: do not use a cache string for version found in hg_archive.txt (refs #84)

This was not passing the tagged version number to version.cpp

→ <<cset 35d086074bb5>>

[Steve Borho]

the 1.5 release included a tar-ball available on our downloads page.

[Steve Borho]

https://bitbucket.org/multicoreware/x265/downloads/x265_1.5.tar.gz

future releases will be uploaded to the same location following the same naming scheme