Why are you updating your VERSION twice?

drbrain | Sun, 10 Jul 2011 01:10:00 GMT

Posted in

I was looking at a project on GitHub and noticed two commits, one after the other, each updating the version of the project in different files.

Then I looked through GitHub's popular forked repositories list and picked out the first several ruby projects and poked through them to see how many made multiple commits to update the version.

While my sample size was only seven or eight ruby libraries, only one updated the version in one place. (Looking through other gems in the past has shown me that most gem maintainers update their versions in multiple files, so pointing out the guilty would be pointless.)

I'm continually puzzled that Ruby projects don't apply the DRY principle to what I have found to be the most error-prone portion of being a library maintainer, releasing the library correctly.

Since Ryan and I put Hoe together there have been several other projects that claim various benefits over Hoe, but I haven't seen a single one that has the "single, unambiguous, authoritative representation" for such a basic piece of information as the version.

Looking through the commit messages of the popular project, one project was released with differing versions between the gemspec and the VERSION constant. Why use a release tool (or process) that allows this to happen? Hoe doesn't! It checks to make sure the VERSION you release matches up with the VERSION in your source (the single, unambiguous authoritative representation) so you can't do that!

Please, please, look at the tools you use to manage your project. Do they make you do extra work like editing the same data twice? Do they prevent you from shooting yourself in the foot?

If they don't make your life easier then fix them or ditch them. While I know that Hoe is the best tool available for developing, maintaining and releasing gems, I know that not everyone seems to agree (even though they're wrong ☺). If you don't like Hoe or don't want to switch to Hoe the least you could do is fix the tool you use to help you instead of hinder you. comments

Comments RSS FEED

class MyGreatLibrary
VERSION = ‘0.1.0’
end

Gem::Specification.new do |g|
…
g.version = MyGreatLibrary::VERSION
end

I don’t need Hoe(or any other tool) for that.

Rob said 10 minutes later

You can also use [Ore](http://github.com/ruby-ore/ore#readme) or even [Bundler](http://gembundler.com) to generate/release your projects, without worrying about regenerating the gemspec or bad commits.

postmodern said 18 minutes later

@Rob This is true. Although, Jeweler/Hoe/Ore/etc allows you to `gem push`, `git tag`, etc, with one command. Also, Ore will not let you build/install/release a gem, if there are uncommitted changed. I tend to find projects without a ChangeLog or any version tags, because the author was just running `gem build myproject.gemspec && gem push myproject-0.1.0.gem`.

postmodern said about 1 hour later

No Rob, you don’t, but after I got past 10 libraries it got really annoying to walk through the same process for every gem I wanted to release.

While referring to your version from the place you create the Gem::Specification helps have a single, authoritative data source for a single project it doesn’t create the same type of data source across multiple gems. Do you really want to specify how to run tests or how to generate and upload documentation for each project? Then change it for each project when you find a better way?

I used to do this, but realized it was a waste of my time and energy I could better spend making my libraries better so I pushed all that information out of my project’s Rakefiles and let Hoe take care of it for me.

Eric Hodel said about 2 hours later

@drbrain That is too true. When you spend more time copying/editing files, you might as well use a project generator. Also, project generators that are not customizable end up wasting your time, since you have to re-edit the boilerplate files. With Ore you can define default options in `~/.ore/options.yml` and install custom templates.

Although, it’s easy to copy-in a boilerplate Rakefile, since most Tasks load configuration from dot-files; RSpec::Core::RakeTask.new loads .rspec and YARD::Rake::YardocTask.new loads .yardopts.

postmodern said about 3 hours later

Comments are disabled