You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's unclear to me if the desired result was to remove the include_buildnum argument to version_string or if this was an oversight. This error will always occur if true is passed as the argument.
stacktrace:
uninitialized constant PG::REVISION
Did you mean? PG::VERSION
# /usr/local/bundle/gems/pg-1.3.0/lib/pg.rb:60:in `version_string'
The text was updated successfully, but these errors were encountered:
The PG::REVISION was properly set until pg-1.1.3, but didn't change afterwards. So it was broken for the last releases. Now with pg-1.3.0 it was removed, but it was an oversight, that the constant is still used in PG.version_string(true).
@ged What do you think? Should we add some kind of git hash as the revision? As part of gem build or release process?
Or should we remove the revision from PG.version_string and make the argument unused?
Since adding a git revision to the gem complicates the release process, I vote for the latter way.
Trying to upgrade a project from 1.2.3 to 1.3.0 and have run into an error with a missing REVISION constant. I think this can be traced back to eb25f07#diff-bb4598a0d0b73ebc79a2abfdd1b879e0d149006c87c6fccd5455105046caeaea this commit where VERSION was moved and REVISION was removed.
It's unclear to me if the desired result was to remove the
include_buildnum
argument to version_string or if this was an oversight. This error will always occur if true is passed as the argument.stacktrace:
The text was updated successfully, but these errors were encountered: