Shoes Minor and Tiny version unavailable

[shoes]

Shoes Minor and Tiny version unavailable

[ccoupe]

The old Shoes 3.1 code computed a revision level (a count of the number of commits) Back in the old days when my commits got stacked up in the pull Q at the mothership - that number never changed always r1718 or maybe it r1778. Also every time you did a rake it would pull the number down from github which took longer than the compile. Even longer if you were offline. That's why I got rid of VERSION.txt

Now that we have shoes3/shoes3.git, the number does increment but I don't want to inflict the online lookup penalty on every rake performed by every team member or casual cloner. For #65 i created the VERSION.txt when packaging Shoes for distribution which is a slow process we don't do that often. Whats a few seconds more going to hurt there? It's just one line to add to every task.rb and a modification to cache.rb to parse VERSION.txt and create the Shoes::REVISION constant. Loose Shoes refuses to package but it could create VERSION.txt on 'rake install'

The major/minor/teeny numbers (and the build date) are from version.h which is generated on every rake (app.yaml). There was (still is?) #ifdef's that depend on them being numeric in C's world view. Which is wrong (IMO). They should be strings.

BuildDate should include hh:mm and be parse able with Ruby Date (or Time or DateTime or whatever is used now days). It should probably be in UTC and not local time. Cobbler and the Splash screen can convert from utc to local time if needed.

[ccoupe]

After more thought, perhaps we should just add new SHOES constants - we can keep the older stuff and use the new stuff.

      SHOES::Version - string, example "3.2.22"
      SHOES::Version_Major int, example  3
      SHOES::Version_Minor int,  example 2
      SHOES::Version_Tiny  int,  example 22
      SHOES::Version_Name  string,  example "federales"
      SHOES::Version_Revision int, example 1854
      SHOES::Version_Date string y-m-d:h:m, example "2015-02-19:21:13" (UTC by definition).
      SHOES::Version_Platform  string, example "i386-mingw"
      SHOES::Version_Full - string. Also contents the of VERSION.tx,t example:
        "shoes federales 3.2.22 r(1854) 2015-02-19:21:13 x86_64-linux"

If you feel that all upper case is the way to go, If SHOES::VERSION_REVISION looks better to you then now would be a good time to SHOUT or Platform should be ARCH. I don't have strong feelings about either. Changing the sematics of SHOES::VERSION might be a problem but probably not.

[IanTrudel]

I prefer capital letters because the convention for constants is such. Also, PLATFORM might be a better name for newbies than ARCH.

The date string is not UTC and is confusing because the day might be confused with hours (h:m:s). It would be safer to just use Time class and easier to parse back later on.

irb(main):001:0> Time.now
=> 2015-02-16 07:14:26 -0500

[ccoupe]

It's upper case constants and PLATFORM.

Of course, VERSION.txt isn't going to work the way I first thought it would so I innovated (sounds better than hacked) a solution. In app.yaml is a revision: entry which can be 'git'. If it is then I create the REVISION from the number of git commits. It can also be set to a number you make up or it can be set to 'file' in which case it parses the VERSION.txt for get the rev number. All of the rake files (env.rb and tasks.rb) will eventually need to be modified to use the new symbols but that needed to be done.

[ccoupe]

Added https://github.com/Shoes3/shoes3/wiki/App.yaml-secrets to describe how app.yaml controls revisions number.

[IanTrudel]

The Splash screen now displays a full UTC formatted build date based on the changes covered on this issue. The format you used in the recent revision would be preferable: 3.2.22 r1833. Or, alternatively, a short format build date would be acceptable as previously displayed.

[IanTrudel]

The solution to this issue seems to be fully implemented.