FreeTDS Development Group

["James K. Lowden" <jklowden AT freetds.org>]

On Sat, 10 Mar 2012 16:32:35 -0500
Ken Collins <ken AT metaskills.net> wrote:

> First, I tend to follow a semantic versioning policy
> (http://semver.org/) and follow others best practices. But what works
> for me is generally tied to the success of rubygems as a whole. So my
> system(s) general reflect other projects in the same sphere. I think
> a good example is the rails project.

OK, so you're packaging.  I get it, or at least I think I do.  I'd
boil down "semantic versioning" to:

1.  A version label refers to a version of source code.  Changing that
source code without changing the label defeats the purpose of the
label.  

2.  The libtool policy for versioning is worth emulating.  

That is *very* widely done, almost universally.  Some years back I
collaborated on a now-defunct packaging system "pkgjam".  We found that
all the packages in pkgsrc could be interpreted according to rules much
like semver.org.  We were able to algorithmically derive an integral
version number for every package based on the name of its released
tarball.  

We have followed the same policy in FreeTDS with the exception that,
for convenience, we provide a "patched release" tarball.  It is
unversioned and does change, and is therefore unsuitable for
packaging.  In the past, we eagerly provided patch releases, too (e.g.
0.64.2) but latterly I haven't felt the need and no one else
volunteered.  FreeTDS is pretty stable from a release point of view.
It's rare that errors mandating a patch are found in releases.  Mostly
we're adding functionality for the next release.  

It's actually because of that stability that I proposed "automatic
patch releases", wherein commits to the release branch would
automatically generate a uniquely labelled tarball.  I am hopeful that
will assuage packagers' concerns and permit them to incorporate release
patches reliably and automatically.  

Someone following along at home might ask what kind of crazy fool
"automatically releases" something?  What of testing?  The answer is
that in practice very little testing ever happened to release patches.
There is no "beta" for release patches.  The patch is usually small and
locally verified to address some specific issue.  If it proves
problematic, it is superseded by the next version (which could be, but
IIRC never was, based on a backing out the patch).  Packagers in my
experience understand these issues and make their choices based on what
they know about the patch. Our job, as developers of the library, is to
be transparent about the purpose and content of the patch.  We address
that mainly through ChangeLog; details are always available on this
list.  :-)

--jkl