Skip to content

Conversation

@radar
Copy link
Contributor

@radar radar commented Feb 13, 2018

Hi there 👋

I noticed that in this commit you bumped the version but did not change the date field in the rake.gemspec. This means that on rubygems.org, Rake 12.2.1 and Rake 12.3.0 were seemingly released on the same day, but the commits show a different history. (The last released date was this commit but it has since been bumped on master with this commit.

May I suggest removing the date field from the gemspec? This way, RubyGems.org will automatically assign the current date to the package's release and it means that you as a maintainer will have to do one less thing every time you release a new version. We do not have a date field in the i18n gem's gemspec and it works just fine.

What do you think?

Hi there 👋

I noticed that in [this commit](ruby@6258ad5) you bumped the version but did not change the `date` field in the `rake.gemspec`. This means that on rubygems.org, Rake 12.2.1 and Rake 12.3.0 were seemingly released on the same day, but the commits show a different history. (The last released date was [this commit](ruby@e7ea2d1) but it has since been bumped on master with [this commit](ruby@0c4aab8).


May I suggest removing the `date` field from the `gemspec`? This way, RubyGems.org will automatically assign the current date to the package's release _and_ it means that you as a maintainer will have to do one less thing every time you release a new version. We do not have a `date` field in the [`i18n` gem's `gemspec`](https://github.com/svenfuchs/i18n/blob/master/i18n.gemspec) and it works just fine. 

What do you think?
@hsbt
Copy link
Member

hsbt commented Feb 14, 2018

Looks reasonable. Thanks!

@hsbt hsbt merged commit 352c64c into ruby:master Feb 14, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants