Thrift
  1. Thrift
  2. THRIFT-6

Thrift libraries and compiler lack version number

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.0
    • Fix Version/s: 1.0
    • Component/s: Build Process
    • Labels:
      None

      Description

      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.

        Issue Links

          Activity

          Hide
          Jens Geyer added a comment -

          I spend more time when making a release on fixing all the missed files and flags within the source/makefiles/scripts/jenkins/automated tests/etc [...]

          I see, you created a lot of tickets in the last two days. How can we streamline this process? How can we make sure that the missing things are recognized early?

          Show
          Jens Geyer added a comment - I spend more time when making a release on fixing all the missed files and flags within the source/makefiles/scripts/jenkins/automated tests/etc [...] I see, you created a lot of tickets in the last two days. How can we streamline this process? How can we make sure that the missing things are recognized early?
          Hide
          Jake Farrell added a comment -

          -1 to another script. I spend more time when making a release on fixing all the missed files and flags within the source/makefiles/scripts/jenkins/automated tests/etc than I do changing the version flag for the non automated client libs. I am all for simplifying things as much as possible, but it should be to our advantage and not add complexity

          Show
          Jake Farrell added a comment - -1 to another script. I spend more time when making a release on fixing all the missed files and flags within the source/makefiles/scripts/jenkins/automated tests/etc than I do changing the version flag for the non automated client libs. I am all for simplifying things as much as possible, but it should be to our advantage and not add complexity
          Hide
          Roger Meier added a comment -

          here is an initial version of the updateversion.sh script.
          Might be an option to merge it with bootstrap.sh and do these version updates with additional command line parameters.

          I'm a big fan of having 1.0.0-c3b2e24 instead of 1.0.0-dev especially for local release and jenkins builds.

          the source shall always keep 1.0.0-dev or right now probably better 0.9.0-dev because a 0.9.1 release is planned, I suggest this:

          release:     0.9.0
          source code: 0.9.0-dev
          local build: 0.9.0-c3b2e
          release:     0.9.1
          source code: 0.9.1-dev
          local build: 0.9.1-a8b9e
          

          -roger

          Show
          Roger Meier added a comment - here is an initial version of the updateversion.sh script. Might be an option to merge it with bootstrap.sh and do these version updates with additional command line parameters. I'm a big fan of having 1.0.0-c3b2e24 instead of 1.0.0-dev especially for local release and jenkins builds. the source shall always keep 1.0.0-dev or right now probably better 0.9.0-dev because a 0.9.1 release is planned, I suggest this: release: 0.9.0 source code: 0.9.0-dev local build: 0.9.0-c3b2e release: 0.9.1 source code: 0.9.1-dev local build: 0.9.1-a8b9e -roger
          Hide
          Jens Geyer added a comment -

          •replace -dev suffix always with "git rev-parse --short HEAD" ?
          •use "git rev-parse --short HEAD" also for releases ?

          Maybe as an addon, but not as an replacement. The '-dev' makes it clear from the beginning what it is, I personally like that. Having the git hash is a nice thing too, since it clearly indicates the exact content of the binaries. So I'd prefer to have it both.

          •how do we version csharp and delphi with the quadruple pattern 0.0.0.0 ? I triple allowed?
          •how to differentiate between release and development version?
          release: 0.9.1.1
          development: 0.9.1.0

          It's not primarily a Delphi/C# thing. Common standard on Windows (because of the OS support) are version numbers with 4 parts. There are some minor differences opinions on how to use them though. Microsoft prefers Major.Minor.Build.Revision, while others prefer Major.Minor.Revision.Build. The main reason of this confusion is a slightly different understanding of what the terms "Revision" and "Build" actually mean. A good explanation can be found here

          With regard to Thrift, I think what you proposed here is not so bad:

          [assembly: AssemblyVersion("0.9.1.0")]
          [assembly: AssemblyFileVersion("0.9.1.0")]
          [assembly: AssemblyInformationalVersion("0.9.1.0-2ca9c20")]

          hence the dev-build would be

          [assembly: AssemblyInformationalVersion("0.9.1.0-dev-8c64dc1")]

          Show
          Jens Geyer added a comment - •replace -dev suffix always with "git rev-parse --short HEAD" ? •use "git rev-parse --short HEAD" also for releases ? Maybe as an addon, but not as an replacement. The '-dev' makes it clear from the beginning what it is, I personally like that. Having the git hash is a nice thing too, since it clearly indicates the exact content of the binaries. So I'd prefer to have it both. •how do we version csharp and delphi with the quadruple pattern 0.0.0.0 ? I triple allowed? •how to differentiate between release and development version? release: 0.9.1.1 development: 0.9.1.0 It's not primarily a Delphi/C# thing. Common standard on Windows (because of the OS support) are version numbers with 4 parts. There are some minor differences opinions on how to use them though. Microsoft prefers Major.Minor.Build.Revision, while others prefer Major.Minor.Revision.Build. The main reason of this confusion is a slightly different understanding of what the terms "Revision" and "Build" actually mean. A good explanation can be found here With regard to Thrift, I think what you proposed here is not so bad: [assembly: AssemblyVersion("0.9.1.0")] [assembly: AssemblyFileVersion("0.9.1.0")] [assembly: AssemblyInformationalVersion("0.9.1.0-2ca9c20")] hence the dev-build would be [assembly: AssemblyInformationalVersion("0.9.1.0-dev-8c64dc1")]
          Hide
          Roger Meier added a comment -

          align several version definitions

          Show
          Roger Meier added a comment - align several version definitions
          Hide
          Roger Meier added a comment -

          It is still pain to update all Versions or add a build number to the Thrift libraries ... a nightmare.
          and the blocker for frequent releases.

          We currently describe the process on versioning here:
          http://thrift.apache.org/docs/committers/HowToVersion

          I currently work on a shellscript to update all Version Info within Apache Thrift source files.

          Goal:

          • shell script to be executed before build
            • create the release: sh contrib/updateversion.sh 0.9.1 release
              • set release version
              • set git hash tag
            • after a release, update source tree: sh contrib/updateversion.sh 0.9.2
              • set new development version
            • do a regular build and add the git hash to the version: sh contrib/updateversion.sh
              • set git hash tag
          • provide info on debian/control, doap.rdf & co

          Questions I like to discuss:

          • replace -dev suffix always with "git rev-parse --short HEAD" ?
          • use "git rev-parse --short HEAD" also for releases ?
          • how do we version csharp and delphi with the quadruple pattern 0.0.0.0 ? I triple allowed?
            [assembly: AssemblyVersion("0.9.1.0")]
            [assembly: AssemblyFileVersion("0.9.1.0")]
            [assembly: AssemblyInformationalVersion("0.9.1.0-2ca9c20")]
            
          • how to differentiate between release and development version?
            release: 0.9.1.1 or
            development: 0.9.1.0

          please provide feedback, the script is ready very soon.
          -roger

          Show
          Roger Meier added a comment - It is still pain to update all Versions or add a build number to the Thrift libraries ... a nightmare. and the blocker for frequent releases. We currently describe the process on versioning here: http://thrift.apache.org/docs/committers/HowToVersion I currently work on a shellscript to update all Version Info within Apache Thrift source files. Goal: shell script to be executed before build create the release: sh contrib/updateversion.sh 0.9.1 release set release version set git hash tag after a release, update source tree: sh contrib/updateversion.sh 0.9.2 set new development version do a regular build and add the git hash to the version: sh contrib/updateversion.sh set git hash tag provide info on debian/control, doap.rdf & co Questions I like to discuss: replace -dev suffix always with "git rev-parse --short HEAD" ? use "git rev-parse --short HEAD" also for releases ? how do we version csharp and delphi with the quadruple pattern 0.0.0.0 ? I triple allowed? [assembly: AssemblyVersion("0.9.1.0")] [assembly: AssemblyFileVersion("0.9.1.0")] [assembly: AssemblyInformationalVersion("0.9.1.0-2ca9c20")] how to differentiate between release and development version? release: 0.9.1.1 or development: 0.9.1.0 please provide feedback, the script is ready very soon. -roger
          Hide
          Roger Meier added a comment -

          just committed:
          update Version Info for several languages and add print-version to Makefile.am

          Show
          Roger Meier added a comment - just committed: update Version Info for several languages and add print-version to Makefile.am
          Hide
          Bryan Duxbury added a comment -

          Sure, let's update all the version numbers. While you're at it, can you record all their locations on http://wiki.apache.org/thrift/HowToRelease ?

          Show
          Bryan Duxbury added a comment - Sure, let's update all the version numbers. While you're at it, can you record all their locations on http://wiki.apache.org/thrift/HowToRelease ?
          Hide
          Roger Meier added a comment -

          patch THRIFT-6_align_version_and_description_to_0.6.0-dev.patch updates all known version files to 0.6.0-dev

          I propose to apply that.

          Currently I work out a solution to maintain or update that version info.
          I think It is only required to update that information during one of the following processes:

          • prepare or creating a release
          • update trunk after publishing a release
          Show
          Roger Meier added a comment - patch THRIFT-6_align_version_and_description_to_0.6.0-dev.patch updates all known version files to 0.6.0-dev I propose to apply that. Currently I work out a solution to maintain or update that version info. I think It is only required to update that information during one of the following processes: prepare or creating a release update trunk after publishing a release
          Hide
          Anthony Molinaro added a comment -

          Yeah, I wrote my opinion on this on the dev list, so I'm sure you all saw it, but I do think having a single unified version is worth it. For most people it means they'll have had to run configure one time to be able to build. But since most people will probably follow the download, untar, ./configure && make recipe they probably already do this anyway?

          One other alternative which I don't necessarily agree with is to completely split thrift up into completely separate pieces, versioned separately. But the compiler ends up being the tricky bit there, in that usually a version of the generated code matches the runtime library for a language. We could try to split the compiler into a runtime component and a bunch of dynamically loaded modules, then you package a language plugin for thrift which contains the generator library, plus the runtime library. That would be neat as you could release new languages without central control, but it would suck in that it'd be hard to test all combinations (it's already hard when they are all next to each other, now imagine they are spread out over 10 different repositories and all versioned separately).

          Anyway more discussion is always welcome before we commit to one or the other.

          Show
          Anthony Molinaro added a comment - Yeah, I wrote my opinion on this on the dev list, so I'm sure you all saw it, but I do think having a single unified version is worth it. For most people it means they'll have had to run configure one time to be able to build. But since most people will probably follow the download, untar, ./configure && make recipe they probably already do this anyway? One other alternative which I don't necessarily agree with is to completely split thrift up into completely separate pieces, versioned separately. But the compiler ends up being the tricky bit there, in that usually a version of the generated code matches the runtime library for a language. We could try to split the compiler into a runtime component and a bunch of dynamically loaded modules, then you package a language plugin for thrift which contains the generator library, plus the runtime library. That would be neat as you could release new languages without central control, but it would suck in that it'd be hard to test all combinations (it's already hard when they are all next to each other, now imagine they are spread out over 10 different repositories and all versioned separately). Anyway more discussion is always welcome before we commit to one or the other.
          Hide
          David Reiss added a comment -

          The one downside of using .in files is that some of the language libraries (like Java and Python) can currently be built without running configure.

          Show
          David Reiss added a comment - The one downside of using .in files is that some of the language libraries (like Java and Python) can currently be built without running configure.
          Hide
          Anthony Molinaro added a comment -

          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.

          Show
          Anthony Molinaro added a comment - 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.
          Hide
          Bryan Duxbury added a comment -

          Roger - thanks for putting the work in to investigate.

          I think that we should start creating tickets to harmonize management of the version number. Ideally, we'd just maintain the number in Makefile.am; if someone with more autoconf/make experience can make a make target that can be run to print out the version, then I think it'd be easy to integrate that with Ruby and Java, for instance.

          As far as the point you raised about the version number style, I'm in favor of trunk having the -dev suffix, so I think we should allow a string at the end of the version. I'm not sure that the "-dev" needs to make it into every spot where we have a version number, though, so I don't think we need to reinvent any wheels there.

          Show
          Bryan Duxbury added a comment - Roger - thanks for putting the work in to investigate. I think that we should start creating tickets to harmonize management of the version number. Ideally, we'd just maintain the number in Makefile.am; if someone with more autoconf/make experience can make a make target that can be run to print out the version, then I think it'd be easy to integrate that with Ruby and Java, for instance. As far as the point you raised about the version number style, I'm in favor of trunk having the -dev suffix, so I think we should allow a string at the end of the version. I'm not sure that the "-dev" needs to make it into every spot where we have a version number, though, so I don't think we need to reinvent any wheels there.
          Hide
          Roger Meier added a comment -

          please have a look on http://wiki.apache.org/thrift/HowToVersion

          I would like to solve this issue before 0.6.0!

          Show
          Roger Meier added a comment - please have a look on http://wiki.apache.org/thrift/HowToVersion I would like to solve this issue before 0.6.0!
          Hide
          Roger Meier added a comment -

          Version information and description should be the same for all deployment formats, debian/control is the relevant file

          Show
          Roger Meier added a comment - Version information and description should be the same for all deployment formats, debian/control is the relevant file
          Hide
          Roger Meier added a comment -

          maven pom.xml needs version info as well, today injected via ivy.xml

          Show
          Roger Meier added a comment - maven pom.xml needs version info as well, today injected via ivy.xml
          Hide
          Roger Meier added a comment - - edited

          existing Thrift Library Version defines:

          $ grep -r "0\.6" * | grep -v .svn
          configure.ac:AC_INIT([thrift], [0.6.0-dev])
          lib/rb/Rakefile:    p.version = "0.6.0"
          

          other candidates:

          lib/py/setup.py:  version = '0.1',
          lib/perl/lib/Thrift.pm:  our $VERSION = '0.1';
          lib/csharp/ThriftMSBuildTask/Properties/AssemblyInfo.cs:  [assembly: AssemblyVersion("1.0.0.0")]
          lib/hs/Thrift.cabal:  Version:        0.2.0
          lib/java/ivy.xml:  <info organisation="org.apache.thrift" module="libthrift" revision="0.3.0-20100116" >
          

          How to bring these things into a release?
          Which languages are missing here and not covered via VERSION define from configure.ac?

          Show
          Roger Meier added a comment - - edited existing Thrift Library Version defines: $ grep -r "0\.6" * | grep -v .svn configure.ac:AC_INIT([thrift], [0.6.0-dev]) lib/rb/Rakefile: p.version = "0.6.0" other candidates: lib/py/setup.py: version = '0.1', lib/perl/lib/Thrift.pm: our $VERSION = '0.1'; lib/csharp/ThriftMSBuildTask/Properties/AssemblyInfo.cs: [assembly: AssemblyVersion( "1.0.0.0" )] lib/hs/Thrift.cabal: Version: 0.2.0 lib/java/ivy.xml: <info organisation= "org.apache.thrift" module= "libthrift" revision= "0.3.0-20100116" > How to bring these things into a release? Which languages are missing here and not covered via VERSION define from configure.ac?

            People

            • Assignee:
              Roger Meier
              Reporter:
              Bryan Duxbury
            • Votes:
              1 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:

                Development