search

rubygems / bundler

Manage your Ruby application's gem dependencies
https://bundler.io
MIT License
4.88k stars 1.99k forks source link

`bundle gem` command doesn't create a CHANGELOG #3326

Closed olivierlacan closed 9 years ago

olivierlacan commented 9 years ago

Since we generate lovely README and LICENSE files when people use bundle gem <gemname>, wouldn't it be a good idea to generate a boilerplate CHANGELOG as well?

I've gathered some conventions over at http://keepachangelog.com/ and although it's rare to see a 0.0.1 version with much notable changes, it would be a good incentive for gem authors to start keeping a change log from the get go.

Here's an example: https://github.com/olivierlacan/keep-a-changelog/blob/gh-pages/CHANGELOG.md

If this makes sense to you all, I'm willing to submit a pull request with the necessary changes. Thanks.

simi commented 9 years ago

I'm afraid that bundle gem command is going out of control. IMHO it was meant to be a simple skeleton generator. Now it is monster with a lot of options and still growing.

bundle gem should be freezed until bundler 2.0 and removed (planed by bundler team AFAIK - refactored into bundler plugin) in 2.0 dev branch.

@indirect will be this kind of patch accepted? Maybe should I open discussion in bundle-features?

For example https://github.com/bundler/bundler/blob/master/lib/bundler/cli/gem.rb#L56-L60 is crazy IMHO. Bundler is duplicating rspec init stuff. Seriously, you're going to write a new gem, it means lines of code. Is it really big problem to run rspec --init after bundle gem also?

TimMoore commented 9 years ago

I agree with @simi... the whole gem skeleton creation feature is pretty tangential to Bundler's main purpose. It may have been necessary when Bundler was brand new, but now that it's well established, I think it would be better to move gem templating out into a dedicated tool.

I like the idea of urging people to maintain CHANGELOG files, and love the keepachangelog.com site, but really the hard part is keeping it up to date, not adding the file in the first place. As discussed over in #3305, we can't really make people commit to something just by dropping a file in their directory without their consent. What's more, at least with a license or a code of conduct, there is useful boilerplate to add, but with a CHANGELOG on a brand new project, we couldn't really add much more than a file with a title and no content. The worst case scenario would be that it sets a precedent of gems that contain unmaintained or empty CHANGELOG files, which IMO is worse than not having one at all.

Thanks anyway for the suggestion, @olivierlacan and for advocating CHANGELOGs in general.

olivierlacan commented 9 years ago

@simi @TimMoore Thanks for the feedback, and the kind words. Honestly I think this functionality should exist in RubyGems instead of Bundler. It does not belong in a separate gem when there are gem commands to build and push gem already. Imagine telling someone who asked about how to create a Ruby gem to install a gem so they can create a gem, in my mind that sounds a little silly. :smiley:

What about a gem new command then? @indirect

Wouldn't that allow for the removal of the bundle gem command (which I still find very useful) and make it obvious what the recommended structure of a gem should be.

I'd be up for working on that if everyone agrees it's a good idea. I realize it's probably not a good time to be adding gem generation features to Bundler.

That said, @TimMoore I disagree on the usefulness of a CHANGELOG boilerplate. I like what the -t flag — that annoys @simi so much — does: it creates a really basic RSpec example checking for a version number and a failing example to start people off in the red. It's not going to stay as is, and so would an example CHANGELOG entry.

In my experience scouring over crucial gems in the Ruby ecosystem, the problem is not CHANGELOG maintaince, it's that entire projects eschewed them from the start and it's extremely tedious to build one after a few years of releases. I've made several PRs to solve situations like these, they're painful. In my admittedly extreme point of view, a gem without a CHANGELOG is an irresponsible dependency.

kirs commented 9 years ago

@indirect is it really going to be removed in 2.0? /cc https://github.com/bundler/bundler/pull/3313

kirs commented 9 years ago

@olivierlacan @TimMoore I made a PR https://github.com/bundler/bundler/pull/3313 few weeks ago with configurable bundle gem. Passing --changelog option could solve the problem.