Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Browse files

First gem version 0.0.1 instead of 0.0.0

  • Loading branch information...
commit 2bb1e80d07a76414ef482ab9a6f8bcd1a53535c4 1 parent e7ac2ab
@indirect indirect authored
View
2  lib/bundler/templates/newgem/lib/newgem/version.rb.tt
@@ -1,7 +1,7 @@
<%- config[:constant_array].each_with_index do |c,i| -%>
<%= ' '*i %>module <%= c %>
<%- end -%>
-<%= ' '*config[:constant_array].size %>VERSION = "0.0.0"
+<%= ' '*config[:constant_array].size %>VERSION = "0.0.1"

If bundler is using semantic versioning (i.e. http://semver.org/), shouldn't the first release be 0.1.0?

Here is my rational:

If versions are in the form A.B.C where

  • A = non backwards compatible features
  • B = backwards compatible features
  • C = fixes and implementation changes

Therefore:

  • 0.0.0 would mean "no features of any kind", where as
  • 0.0.1 would mean "a bug fix or implementation change for no features", which doesn't make any sense as you can't re-implement or change something that does not exist yet. However,
  • 0.1.0 would mean "the first set of feature(s)".

I'm just curious what your thinking is/was on this.

I appreciate this was done a while back and things have change a lot since then (e.g. semver.org didn't exist). However I think it could do with a re-visit.

What do you think?

@lgierth
lgierth added a note

You are right about the three A.B.C constraints, but they don't apply for versions below 1.0.0. Everything below 1.0.0 is considered unstable and might be changed or removed without warning. If this isn't okay for your library/application, you should probably already be at 1.x.

So basically you should use your own conventions below 1.0.0? This would seem a bit messy.

If you go to the faq "How should I deal with revisions in the 0.y.z initial development phase?" on http://semver.org/ he suggests:

"The simplest thing to do is start your initial development release at 0.1.0 and then increment the minor version for each subsequent release."

Which based on my rational I agree; and believe it to be a good suggestion.

Even below version 1.0.0 I think there is no real reason why good versioning shouldn't be encouraged.

@lgierth
lgierth added a note

Even below version 1.0.0 I think there is no real reason why good versioning shouldn't be encouraged.

Indeed! SemVer just leaves conventions undefined for versions below 1.0, because it considers those unstable, and this has different implications for different kinds of software.

Thoughtful versioning and incorporation of changes should always be encouraged! :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
<%- config[:constant_array].size.downto(0) do |i| -%>
<%= ' '*i %>end
<%- end -%>
View
6 spec/other/gem_helper_spec.rb
@@ -36,12 +36,12 @@
it "builds" do
@helper.build_gem
- bundled_app('test/pkg/test-0.0.0.gem').should exist
+ bundled_app('test/pkg/test-0.0.1.gem').should exist
end
it "installs" do
@helper.install_gem
- should_be_installed("test 0.0.0")
+ should_be_installed("test 0.0.1")
end
it "shouldn't push if there are uncommitted files" do
@@ -49,7 +49,7 @@
end
it "pushes" do
- @helper.should_receive(:rubygem_push).with(bundled_app('test/pkg/test-0.0.0.gem').to_s)
+ @helper.should_receive(:rubygem_push).with(bundled_app('test/pkg/test-0.0.1.gem').to_s)
Dir.chdir(@app) {
`git init --bare #{gem_repo1}`
`git remote add origin file://#{gem_repo1}`
Please sign in to comment.
Something went wrong with that request. Please try again.