initial commitHEADmaster

1 files changed, 89 insertions, 0 deletions

diff --git a/version.txt b/version.txt
new file mode 100644
index 0000000..dd95c1b
--- /dev/null
+++ b/version.txt
@@ -0,0 +1,89 @@
+Guide to SlackBuilds.org Version Numbers
+========================================
+
+For the most part, you should just use upstream's version number.  The
+only restriction there is that - (hyhen) characters are not allowed in
+Slackware package version numbers. This is a limitation of Slackware's
+pkgtools, so it applies to all SlackBuilds, not just SBo ones.
+
+Illegal Characters
+------------------
+
+If upstream's version number has a - in it, such as "1.2.3-4", change
+it to an underscore (_) and use code like this in the SlackBuild:
+
+VERSION="${VERSION:-1.2.3_4"
+SRCVER="$( echo $VERSION | tr - _ )"
+
+The second line could also be written as:
+
+SRCVER="${VERSION//-/_}"
+
+...which is either more readable, or a hideoous abomination, depending
+on your background.
+
+Packaging a git/SVN/etc Commit
+------------------------------
+
+Sometimes, the software you're packaging doesn't have releases,
+or else the latest release can't be packaged because it contains
+bugs that have been fixed in a later git/svn/etc revision. If you
+have to package a git revision, please don't just use the git commit
+(e.g. a912dead). These are annoying because they can't be sorted or
+compared. SVN revisions do increase so you can sort or compare them,
+but it's still better to use a more informational version number. It's
+recommended that you use either:
+
+[version]+[date]_[revision]
+
+...where [version] is the latest release, [date] is the 8-digit ISO
+date (YYYYMMDD format), and [revision] is the git/SVN/etc commit,
+or else:
+
+[date]_[revision]
+
+...if the upstream project has never done a release.
+
+Examples:
+
+VERSION="1.0+20260829_a912dead"
+VERSION="20260829_a912dead"
+
+If you're packaging a git commit, you'll have to either find a URL
+for a tarball (see github.txt, gitlab.txt, codeberg.txt), or find a
+way to host it on a web server (see hosting.txt).
+
+No Version Number
+-----------------
+
+Some projects just don't have a version number. Usually these are
+simple "one-off" utilities that Just Work and don't need later
+updates (for examples, see system/crc32_simple and audio/alsacap).
+
+The best way to choose a version number for these, if you can't
+find a version in any of the files inside the tarball, is just to
+take the modification date of the newest file in the archive.
+For alsacap, after downloading the source:
+
+$ tar xvf alsacap.tgz
+alsacap/alsacap.c
+alsacap/alsacap.1
+alsacap/alsacap.pod
+alsacap/Makefile
+alsacap/LICENSE
+$ cd alsacap/
+$ ls -lt
+total 40
+-rw-r----- 1 urchlay users 18660 Aug 21  2020 alsacap.c
+-rw-r----- 1 urchlay users  7795 Apr  4  2013 alsacap.1
+-rw-r----- 1 urchlay users  3500 Apr  4  2013 alsacap.pod
+-rw-r----- 1 urchlay users   306 Apr  4  2013 Makefile
+-rw-r----- 1 urchlay users   784 Apr  4  2013 LICENSE
+
+The newest file is listed first. It's Aug 21, 2020, so the
+VERSION for alsacap is 20200821.
+
+Another thing to beware of when packaging a tarball without a
+version in the filename is md5sum mismatches, if upstreams changes the
+tarball. This is especially a problem for active projects that provide
+only a "project-latest.tar.gz". See download.txt for more information.