On Tuesday 10 August 2010, Marnen Laibow-Koser wrote:
> Michael Schuerig wrote:
> > On Tuesday 10 August 2010, Marnen Laibow-Koser wrote:
> >> Then, instead of a meta tag, why not just put it in a hidden (or
> >> smallish) div in the HTML?
> >
> > Why? I don't see what I would gain.
>
> If it's not hidden, the user can actually *see* the build number
> rather than having to send you the HTML source. (This is the
> approach we use here at work.)
No way, I'm constrained by the visual design people.
> Besides, <meta name="version"> is meant for the version of the
> *document*, not the version of the *application* that built it, isn't
> it?
It's no big deal changing "version" to "app-version".
> > I may need to mention that I'm not
> > actually overwriting a file. The partial containing the explicit
> > call to git is contained in an engine common to several
> > applications. The partial I write that's containing the deployed
> > version is in the app itself and therefore earlier in the path.
>
> But you *are* overwriting a file. Your initial post with your Cap
> recipe says that you're doing just that.
Trust me, I'm not overwriting anything. Yes, I wrote so originally, but
that was only for easier explanation. When I had to go into the details,
I clarified that I'm not overwriting, but rather overriding.
> >> And I think Parker may have the right idea. It seems reasonable
> >> to read this from a VERSION file that's updated by Git or Cap.
> >
> > That doesn't explain why that approach is better than what I'm
> > currently doing. Yes, it does seem reasonable, but is my current
> > approach unreasonable?
>
> I think it is. It seems extremely hackish. The build number is an
> application-wide constant, so it should be defined as a Ruby constant
> (so that the app can be aware of it) instead of just hacked into an
> ERb partial.
>
> In other words, the same code that now writes <meta name="version"
> content="#{tag}"> in your partial should probably be changed to write
> VERSION=#{tag} in some initializer file. Then the partial can just
> read VERSION -- and so can anything else that needs to know the
> build number.
I don't like that. I need to write that file in my development
environment, possibly using a git post-commit hook. When there are
uncomitted changes, the version I get is outdated. Using
`git describe --tags --always --dirty`
in a partial, I get an indication that I'm looking at a page generated
from an uncommitted version.
Here are the desiderata:
* The shown version has to be current, not just the last commit.
* In production, no VERSION file is re-read for each request.
During deployment
* The version is frozen to the deployed tag.
* No markup is written.
* No file is overwritten.
Capistrano already writes a REVISION file containing the commit sha1.
Let's assume there's a TAG file, too. Then an initializer like this
would do the job
if Rails.env.production?
version = File.read('TAG').strip
else
version = `git describe --tags --always --dirty`.chomp
end
Rails.application.config.version = version
Michael
--
Michael Schuerig
mailto:[email protected]
http://www.schuerig.de/michael/
--
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Talk" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.
