[
https://issues.apache.org/jira/browse/THRIFT-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12921502#action_12921502
]
Anthony Molinaro commented on THRIFT-6:
---------------------------------------
The correct path since we do use autotools to compile everything is to use the
version in configure.ac. It's very easy to substitute a variable in a file
with configure (its how it works).
For erlang since it already has some make rules to substitute a variable into
the app.src file I just added the following to the Makefile.am
VSN=$(PACKAGE_VERSION)
PACKAGE_VERSION is the name of the version variable set in configure.ac.
So if you already have code being compiled by make you can put it into the
appropriate Makefile.am.
However, there's another pattern you could use for something like java. I'll
describe how it did it with maven, ivy/ant may be different.
I had a maven.xml which had the version in it like
<version>0.2.0</version>
So I rename maven.xml to maven.xml.in, then change the line above to
<version>@PACKAGE_VERSION@</version>
Then I add to configure.ac
AC_CONFIG_FILES([lib/java/maven.xml])
Now what happens is when you run './configure' it will substitute any variables
denoted by @VAR@ with the value detected/set by configure.
As far as appending -dev or something, that should be okay. Some package
managers don't like '-' in version numbers since they use '-' to separate
different components, also sometimes they end up sorting wrong. Ideally you
would want a way for a dev version to sort before the release version, so that
different package managers can deal. It's hard to have a bulletproof version,
but something like when you release 0.5.0 you start using 0.5.0.9999.dev as the
dev version would probably work, then eventually you release 0.6.0,
and your versions sort through the transition.
> Thrift libraries and compiler lack version number
> -------------------------------------------------
>
> Key: THRIFT-6
> URL: https://issues.apache.org/jira/browse/THRIFT-6
> Project: Thrift
> Issue Type: Bug
> Reporter: Bryan Duxbury
> Assignee: Roger Meier
>
> Right now it's impossible to tell which version of Thrift you have installed.
> If you're depending on features that have recently been added (and that
> subtly don't exist), you can spend a lot of time chasing your tail trying to
> figure out what the problem is.
> This may be something that has to be implemented piecemeal on each client
> library (ruby gem, java classes, etc). Thoughts?
> While we're at it, let's add a --version switch or something to the compiler
> so you know what version of stuff you're actually generating.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
