Michael Schuerig wrote:
[...]
>> 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.
They won't let you put it somewhere inconspicuous? Oy.
>
>> 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".
True.
>
>> > 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.
What's the difference? What are you *actually* doing? Your Cap recipe
that you posted pretty clearly overwrites a file. Is that not your
actual recipe?
>> 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.
Why not?
> I need to write that file in my development
> environment, possibly using a git post-commit hook.
Why? It should probably be written in the production environment as
part of the post-deploy process.
[...]
> Here are the desiderata:
>
> * The shown version has to be current, not just the last commit.
What do you mean? The version *is* the last commit, unless I totally
misunderstand.
> * In production, no VERSION file is re-read for each request.
Right now, you're potentially rereading your partial for each request.
A VERSION initializer such as I have suggested would load the constant
in memory once at app startup and never read it again.
>
> 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
This looks to me like just about exactly what I have been suggesting.
Why do you like this and not my suggestions? What are the differences
as you see them?
>
>
> Michael
>
> --
> Michael Schuerig
> mailto:[email protected]
> http://www.schuerig.de/michael/
Best,
--
Marnen Laibow-Koser
http://www.marnen.org
[email protected]
--
Posted via http://www.ruby-forum.com/.
--
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.
