New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Shoes Minor and Tiny version unavailable #50

Closed
BackOrder opened this Issue Jan 30, 2015 · 7 comments

Comments

Projects
None yet
2 participants
@BackOrder
Collaborator

BackOrder commented Jan 30, 2015

Shoes::VERSION and Shoes::REVISION both currently returns 3. The second one should return 2 since it is clearly stipulated:

Shoes::REVISION is the Subversion revision number for this build.

There is currently no way to obtain the tiny version of Shoes. Shoes::VERSION should either return 3 or full version, or perhaps Shoes::FULL_VERSION should be available.

Missing in the manual Shoes > Built-in > _Built-in Constants_:

Shoes::VERSION
Shoes::RELEASE_TYPE
Shoes::RELEASE_BUILD_DATE

@BackOrder BackOrder added the Windows label Jan 30, 2015

@ccoupe ccoupe added this to the 3.2.22 milestone Feb 14, 2015

@ccoupe ccoupe added Normal and removed Windows labels Feb 14, 2015

@ccoupe

This comment has been minimized.

Show comment
Hide comment
@ccoupe

ccoupe Feb 16, 2015

Contributor

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.

Contributor

ccoupe commented Feb 16, 2015

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

This comment has been minimized.

Show comment
Hide comment
@ccoupe

ccoupe Feb 16, 2015

Contributor

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.

Contributor

ccoupe commented Feb 16, 2015

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.

@BackOrder

This comment has been minimized.

Show comment
Hide comment
@BackOrder

BackOrder Feb 16, 2015

Collaborator

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
Collaborator

BackOrder commented Feb 16, 2015

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 ccoupe self-assigned this Feb 17, 2015

@ccoupe

This comment has been minimized.

Show comment
Hide comment
@ccoupe

ccoupe Feb 17, 2015

Contributor

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.

Contributor

ccoupe commented Feb 17, 2015

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

This comment has been minimized.

Show comment
Hide comment
@ccoupe

ccoupe Feb 17, 2015

Contributor

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

Contributor

ccoupe commented Feb 17, 2015

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

@BackOrder

This comment has been minimized.

Show comment
Hide comment
@BackOrder

BackOrder Feb 20, 2015

Collaborator

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.

Collaborator

BackOrder commented Feb 20, 2015

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.

ccoupe added a commit that referenced this issue Feb 20, 2015

Make splash screen build info shorter #50
Fix -v #71 comments - raise SystemExit bug with a date string inside. Go figure.

BackOrder added a commit that referenced this issue Feb 21, 2015

Fixed revision number display in cobbler see #50
Using revision number format rXXXX.
@BackOrder

This comment has been minimized.

Show comment
Hide comment
@BackOrder

BackOrder Feb 21, 2015

Collaborator

The solution to this issue seems to be fully implemented.

Collaborator

BackOrder commented Feb 21, 2015

The solution to this issue seems to be fully implemented.

@BackOrder BackOrder closed this Feb 21, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment