13 Replies Latest reply on Aug 7, 2014 11:55 AM by Jon Tara

    4.1 version string

    Jon Tara

      Is there some good reason why the string in the file version is still 4.0.0 in both 4.1.0 and 4-1-stable branches?


      This labels the Gem, and it's clearly confusing to have different Gems with the same version!

        • Re: 4.1 version string
          Jon Tara

          4-1-stable now has the version file set to string 4.1.0 as of a few days ago. Thanks!


          However, Rhodes version is still clear as mud.


          The version file (which sets the name of the Gem) says 4.1.0.


          The repo has a tag of 4.1.1 on April 17 625df13c, and 'v4.1.1' on March 20 e22017ed


          Current head of 4-1-stable is from June 4, 19646666


          This post:


          .apk not found


          mentions various versions that have neither a tag in the repo nor any version with the version string set to that value.


          The most recent blog post mentions 4.1.6 as the most recent version of Rhodes. I can find no evidence of such a version number in the git repo.


          In short, I have no idea what the version numbers mean or how they correspond to the git repo. Heck, I'm not even sure what product (Rhodes? RhoStudio? Something else?) this number refers to.


          Can we please get some clarity on Rhodes versioning?

            • Re: 4.1 version string
              Jon Tara

              A related issue: Are there release notes? There used to be occasional blog posts, but even then only on certain releases.


              Since I build the Gem myself from the Git repo, of course, I can review all of the changes. But how can others, who shouldn't be expected to have to refer to the repo, know what has changed? Or even if there has been a new release?


              There seems to be no consistency in this.


              I'm baffled by posts here about versions I've never heard of an can find no evidence of in the code or repo.

                • Re: 4.1 version string
                  Kutir Mobility

                  This issue needs help from Motorola. We will raise this issue with them to get an answer.


                  Visnupriya R

                  Kutir Mobility

                  • Re: 4.1 version string


                        I changed the version strings but, it is up to the devs to keep up with that. Unfortunately I have no power over that :/  I'm sure if this causes a huge problem that they will get on it and fix it but right now there are many other issues taking priority.

                      • Re: 4.1 version string
                        Jon Tara

                        Well, yes, it *does* cause a huge problem.Without an accurate version string, for example, bug reports are ambiguous. You could waste a lot of time trying to look for a bug in the wrong branch.


                        Observation: your versioning is completely out of control. It needs to be fixed. I can't tell you how to fix it, but you need to implement a process that makes it clear what users are working with and how it corresponds to the source code (repository). And then you need to implement that policy consistently and make sure every time you release code it is appropriately-labelled. And you need consistent labeling of releases in the repository. It is inconsistent. You have a branch tagged "4.1.1". And you have a branch tagged "v4.1.1". What, if anything, does the distinction mean? Is there some specific tagging policy, or do developers just make-up tags willy-nilly?


                        I'll paste our "about" screen from our app in below. It may give you some useful ideas. When a user reports a problem, we want to know what source code that goes with, and so we provide the information needed to do that...


                        Note that we include the git SHA. It would be very useful if Rhodes included the git SHA and make it available in, say, RhoConfig. It provides an unambiguous reference to a specific git checkin. Better than any version number.


                        Note the red (DIRTY). It means I have changes locally in my working directory that have not been checked-in to the repo. We actually can't produce a production release that is dirty. (Our build process will detect this.)



                          • Re: Re: 4.1 version string
                            Jon Tara

                            Some useful code should the developers wish to make it easier to identify what the heck version a Rhodes app was built with...


                            # Collect some handy information about git configuration

                            def gather_git_config

                              # Get developer's git configuration into a convenient hash of hashes

                              @git_config = {}

                              git_config_list = `git config --list`.split("\n")

                              git_config_list.each do |item|

                                k,v = item.split '='

                                @git_config[k] = v




                              @developer_email = @git_config['user.email'] || ''

                              @developer_name = @git_config['user.name'] || ''

                              @developer_github_user = @git_config['github.user'] || ''



                              if @developer_github_user == ''

                                puts "You must configure github.user in git!".red








                            def gather_git_commit_info

                              @git_commit_hash = `git rev-parse HEAD`.chomp

                              @git_commit_short_hash = `git rev-parse --short HEAD`.chomp

                              @git_local_branch = `git branch | sed -n '/\* /s///p'`.chomp

                              @git_remote_branch = `git rev-parse --symbolic-full-name --abbrev-ref @{u}`.chomp

                              git_dirty_str = `git status --porcelain`.chomp

                              @git_dirty = git_dirty_str != ''




                            # Gather some handy information from command-line git, which we will put in build data

                            def gather_git_info




                          • Re: 4.1 version string
                            Jon Tara

                            This issue has come up again with the release of "Rhomobile Suite 5.0" (really, 5.0.3)


                            I have no way to correlate the Rhodes Gem in the download with the source code in the repo. There is no consistency to version numbers or repo tags/branches.


                            - 5-0-stable has the version file set to 5.0.0. Last checkin was July 10, cc05fcf


                            - master has the version file set to 4.1.0. Last checkin was yesterday. Lots of activity on this branch.


                            There isn't any branch or tag that would suggest that it holds the 5.0.3 version.


                            I have to conclude that the distributed Gem was not built from the git repository, or was modified subsequently (at least the version string...)


                            This makes it impossible to use the repository to discover the details of code changes. It makes it impossible to conduct a security audit, should that be a requirement. Many other reasons why it should be possible to correlate the release with the exact commit in the git repo that it was produced from. Otherwise it is a "pig in a poke".

                      • Re: 4.1 version string
                        Jon Tara

                        FYI, some recent commits to the repo at least sort-out which branch is which. It still does not clarify exactly which commit was used to build the distributed Gem.


                        5-0-stable is apparently stuck at 5.0. This differs from previous policy where the x-y-stable branch had the latest distributed version for the major/minor version number.


                        master is apparently current development, currently labeled (in version file) 5.0.2. So, it is 5.0.2 plus more recent changes. But - the changing of the version string to '5.0.2' is a "more recent change", since apparently, this file was manually altered when 5.0.2 was built for distribution. (It was previously '4.1.0'.


                        We still need some way of identifying exactly which commit corresponds to each release. I'd suggest re-instituting the prior policy of tagging each release commit with the version number, using a git tag.