make a 1.0.0 release?

[jnunemaker]

make a 1.0.0 release?

[matkoniecz]

If big companies have some random requirements that they want fulfilled, then requests to do a random busy work should be accompanied with funding.

And if big company is unwilling to neither drop stupid requirements nor fund workarounds, then why other should care about it?

Also, note the license. You are free to release crack-for-big-companies gem with version tagged as 81728723782728.

[schmijos]

big companies have some random requirements

This is not about random requirements. Be aware that I have to treat 0.x releases as major releases. It's mental overhead for everybody who would like to not break his/her code. I wrote a short note about this issue.

We owe compatibility to Matz.

[kiskoza]

We just made a new v0.4.6 release recently to add support for recent Ruby versions. I'm open to releasing an v1.0.0 too if it makes sense for the community. Apart from this conversation, I got a question from bblimke about getting an 1.0 in the future. As this gem is in a maintenance mode, the goal is to not break existing projects and keep usage of crack easy.

I made a few searches on github using this tool: https://github.com/search?type=code

• language:ruby NOT is:archived NOT is:fork /gem ['"]crack['"]/: 556 occurences. Clicking on a few repos, some of them are pretty old, some of the lines are just comments, though this could be a baseline for my investigation
• language:ruby NOT is:archived NOT is:fork /^ *gem ['"]crack['"]/: 438 occurences. It filters out the commented-out lines as the line must start with spaces or the gem reference. (could be a bit more realistic baseline)
• language:ruby NOT is:archived NOT is:fork /^ *gem ['"]crack['"]$/: 326 occurences. The line only contains gem "crack", no version restriction and no comma to separate a new line
• language:ruby NOT is:archived NOT is:fork /^ *gem ['"]crack['"], ['"]~>/: 26 occurences. The line has a tilde operator to lock in the maximum version. Most of these seems to be abandoned (last change on the default branch was made 4-14 years ago)
• language:ruby NOT is:archived NOT is:fork /^ *gem ['"]crack['"], ['"]</: 1 occurence. This line has a less than operator to lock in the maximum version - it was easy to check, the line is there within an if block to support Ruby 1.9.3
• language:ruby NOT is:archived NOT is:fork /^ *gem ['"]crack['"], ['"]0\.[123]/: 24 occurences. This pattern blocks the project to use latest v0.4.6 already
• language:ruby NOT is:archived NOT is:fork /^ *gem ['"]crack['"], ['"]0\.4/:21 occurences. They are on the latest-ish versions, but apart from one repo, they are not receiving the latest version.

What should we do with these results? I think it's safe to release a v1.0.0. Out of 438 occurences 326 could start using v1 immediately based on their Gemfiles. Most of the remaining projects cannot use our latest version anyways and they need to make a manual update to introduce v0.4.6 (or v0.4.7, etc, in the future...)

So the main questions remains: Do we need a new version called v1.0.0?

[bblimke]

@kiskoza, I would also suggest considering gemspecs, not just Gemfiles. For example, the crack dependency declaration in WebMock is via gemspec, not Gemfile. Here is a list of the most downloaded gems that depend on crack: reverse_dependencies.

Additionally, GitHub search does not display private projects that depend on crack or projects that indirectly depend on it.

In my opinion, a major version release indicates that the API is stable and can be relied upon with semantic versioning. It serves as a promise that the API will not change in minor or patch versions. Since the crack API hasn't changed over the years, I don't foresee any risks. It's more of a nice-to-have.

[kiskoza]

Thanks for your input. I check the reverse dependencies as well and it seems that most of the actively maintained gems allow using v1.0.0 without any required code changes. Let's do the version number bump.