Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Please tag v1.x.x #28

Closed
pda opened this issue May 9, 2014 · 11 comments
Closed

Please tag v1.x.x #28

pda opened this issue May 9, 2014 · 11 comments

Comments

@pda
Copy link

pda commented May 9, 2014

Could you please release and tag a semver v1.x.x?

Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.
Version 1.0.0 defines the public API. The way in which the version number is incremented after this release is dependent on this public API and how it changes.
— http://semver.org/

No meaningful relationship between v0.x.x releases can be inferred. There's no guarantee that v0.7.4 will be in any way compatible with v0.7.3.

This means library authors need to lock their dependencies to the patch-version, making interoperability painful. For example landrush.gemspec locks to rubydns 0.7.0 while vagrant-dns.gemspec locks to rubydns 0.6.x, so they can't both be loaded at once.

A v1.0.0 release doesn't need to be finished or perfect, it just defines the backwards-compatibility semantics moving forwards, and should be released pretty much as soon as the code is being used in the wild.

Thanks!
This was referenced May 9, 2014
Closed
Closed
@ioquatix
Copy link
Member

ioquatix commented May 9, 2014

Hi thanks for your feedback. This gem hasn't ever had a stable API and things have changed quite a bit (even between 0.6.x and 0.7.x), however I do maintain compatibility between minor versions.

A 1.0 release could be sooner rather than later now that I've implemented all the functionality I wanted, but I like to let things settle a bit before doing 1.0 because as you've said this should be a stable and mostly bug free release.

I'll review the situation in more detail and see what is appropriate.

@pda
Copy link
Author

pda commented May 9, 2014

Cool, thanks for the considered response.

I'm not sure v1.0.0 needs aim for bug-free; that can be addressed by patch-level version bumps. As for stability of the API; there's probably enough people using it now that backwards incompatible changes will be painful. Tagging current as v1.0.0 means you can signal those changes via a v2.0.0 release in future.

Thanks for the open-source code, and I hope you don't mind me ranting about my versioning opinions :)

@ioquatix
Copy link
Member

Okay so I remembered two of the last remaining things I wanted to do:

  • Remove the dependency on RExec, which I did today and
  • Add support to automatically add RubyDNS servers to the system resolver (haven't done yet).

I've released 0.8.0 which will probably become the 1.0.0 release. If possible, I'll get people to test with 0.8.0 and then if there aren't any issues within two weeks I'll make 1.0.0 release.

@ioquatix
Copy link
Member

By the way, you should definitely be using the latest 0.7.x release as there are some issues with the older releases. Ideally, going forward, target 0.8.x and then within two weeks there will be a 1.0 release.

@fnordfish fnordfish mentioned this issue May 11, 2014
Merged
2 tasks
This was referenced May 17, 2014
Closed
Closed
Open
Closed
Closed
Closed
Closed
Open
@petergoldstein
Copy link
Contributor

@ioquatix With the recent change from EventMachine to Celluloid in the 0.9.x version do you have an updated timeline for a 1.0 release? Is there anything that I can do to help get RubyDNS to a 1.0? Thanks.

@ioquatix
Copy link
Member

@petergoldstein Testing, testing and more testing :)

The timeline is by the end of this year, but it also will depend on the outstanding bugs in Celluloid and whether they get resolved..

I'm currently trying to fix this one (I've got a half assed work around which I'll try today):

celluloid/celluloid-io#121

Less important is this one:

celluloid/celluloid#466

@ioquatix
Copy link
Member

Another issue which is currently hacked around in RubyDNS:

celluloid/celluloid#436

@ioquatix
Copy link
Member

While less important, getting the examples all working again would be useful since people use them as starting points.

@petergoldstein
Copy link
Contributor

@ioquatix Ok, let me start with the examples because there's less of a learning curve than diving into Celluloid internals. Thanks for the update!

@ioquatix
Copy link
Member

So, the first example I restored was the wikipedia DNS. It had some minor spelling error in a module name and the HTTP requester was based on em-http which is obviously not relevant any more.

I've added two more example files 9227809 - they need to be tested. They might need to have documentation updated (e.g. RExec is no longer used). It's also useful for people to add in to the file, an example of what dig command to run and what output you'd expect.

@petergoldstein Those two examples, if you can test them and bring them "up to spec" that would be great.

swrobel added a commit to swrobel/invoker that referenced this issue Oct 26, 2014
@swrobel
Lock RubyDNS to 0.8.x versions
d938006 
Invoker currently does not start on a new install because it will use RubyDNS 0.9.0 which was released on 10/23/14. This took an exceptionally long time to troubleshoot because of celluloid, but I finally tracked it down! Invoker's gemspec locks RubyDNS to `~> 0.7`, however [the author states](socketry/rubydns#28) that `0.x` releases are incompatible, but minor versions should be compatible. Here is the [offending change](socketry/rubydns@v0.8.5...v0.9.0#diff-d86035f01d9c6b072797c19b43eb736aL116) in 0.9.0.
For the time being you can add the following to your own `Gemfile`:

`gem 'rubydns', '~> 0.8.5'`

Here is a trace of what happens when you run with RubyDNS 0.9.0:
```
→ invoker start Procfile 
D, [2014-10-26T09:45:30.515304 #59891] DEBUG -- : Terminating 1 actor...
vendor/bundle/gems/celluloid-0.16.0/lib/celluloid/calls.rb:39:in `check': wrong number of arguments (1 for 0) (ArgumentError)
	from vendor/bundle/gems/celluloid-0.16.0/lib/celluloid/calls.rb:24:in `dispatch'
	from vendor/bundle/gems/celluloid-0.16.0/lib/celluloid/calls.rb:63:in `dispatch'
	from vendor/bundle/gems/celluloid-0.16.0/lib/celluloid/cell.rb:60:in `block in invoke'
	from vendor/bundle/gems/celluloid-0.16.0/lib/celluloid/cell.rb:71:in `block in task'
	from vendor/bundle/gems/celluloid-0.16.0/lib/celluloid/actor.rb:357:in `block in task'
	from vendor/bundle/gems/celluloid-0.16.0/lib/celluloid/tasks.rb:57:in `block in initialize'
	from vendor/bundle/gems/celluloid-0.16.0/lib/celluloid/tasks/task_fiber.rb:15:in `block in create'
	from (celluloid):0:in `remote procedure call'
	from vendor/bundle/gems/celluloid-0.16.0/lib/celluloid/calls.rb:92:in `value'
	from vendor/bundle/gems/celluloid-0.16.0/lib/celluloid/proxies/sync_proxy.rb:33:in `method_missing'
	from vendor/bundle/gems/invoker-1.3.0/lib/invoker/power/powerup.rb:17:in `block in run'
	from vendor/bundle/bundler/gems/eventmachine-4d53154a9ea4/lib/eventmachine.rb:187:in `call'
	from vendor/bundle/bundler/gems/eventmachine-4d53154a9ea4/lib/eventmachine.rb:187:in `run_machine'
	from vendor/bundle/bundler/gems/eventmachine-4d53154a9ea4/lib/eventmachine.rb:187:in `run'
	from vendor/bundle/gems/invoker-1.3.0/lib/invoker/power/powerup.rb:13:in `run'
	from vendor/bundle/gems/invoker-1.3.0/lib/invoker/power/powerup.rb:7:in `block in fork_and_start'
	from vendor/bundle/gems/invoker-1.3.0/lib/invoker/power/powerup.rb:7:in `fork'
	from vendor/bundle/gems/invoker-1.3.0/lib/invoker/power/powerup.rb:7:in `fork_and_start'
	from vendor/bundle/gems/invoker-1.3.0/lib/invoker/process_manager.rb:72:in `run_power_server'
	from vendor/bundle/gems/invoker-1.3.0/lib/invoker/commander.rb:39:in `start_manager'
	from vendor/bundle/gems/invoker-1.3.0/lib/invoker/cli.rb:46:in `start'
	from vendor/bundle/gems/thor-0.19.1/lib/thor/command.rb:27:in `run'
	from vendor/bundle/gems/thor-0.19.1/lib/thor/invocation.rb:126:in `invoke_command'
	from vendor/bundle/gems/thor-0.19.1/lib/thor.rb:359:in `dispatch'
	from vendor/bundle/gems/thor-0.19.1/lib/thor/base.rb:440:in `start'
	from vendor/bundle/gems/invoker-1.3.0/lib/invoker/cli.rb:12:in `start'
	from vendor/bundle/gems/invoker-1.3.0/bin/invoker:7:in `<top (required)>'
	from ./bin/invoker:16:in `load'
	from ./bin/invoker:16:in `<main>'
```
@swrobel swrobel mentioned this issue Oct 26, 2014
Merged
evansagge pushed a commit to evansagge/invoker that referenced this issue Nov 12, 2014
@swrobel @evansagge
Lock RubyDNS to 0.8.x versions
82781bf 
Invoker currently does not start on a new install because it will use RubyDNS 0.9.0 which was released on 10/23/14. This took an exceptionally long time to troubleshoot because of celluloid, but I finally tracked it down! Invoker's gemspec locks RubyDNS to `~> 0.7`, however [the author states](socketry/rubydns#28) that `0.x` releases are incompatible, but minor versions should be compatible. Here is the [offending change](socketry/rubydns@v0.8.5...v0.9.0#diff-d86035f01d9c6b072797c19b43eb736aL116) in 0.9.0.
For the time being you can add the following to your own `Gemfile`:

`gem 'rubydns', '~> 0.8.5'`

Here is a trace of what happens when you run with RubyDNS 0.9.0:
```
→ invoker start Procfile 
D, [2014-10-26T09:45:30.515304 #59891] DEBUG -- : Terminating 1 actor...
vendor/bundle/gems/celluloid-0.16.0/lib/celluloid/calls.rb:39:in `check': wrong number of arguments (1 for 0) (ArgumentError)
	from vendor/bundle/gems/celluloid-0.16.0/lib/celluloid/calls.rb:24:in `dispatch'
	from vendor/bundle/gems/celluloid-0.16.0/lib/celluloid/calls.rb:63:in `dispatch'
	from vendor/bundle/gems/celluloid-0.16.0/lib/celluloid/cell.rb:60:in `block in invoke'
	from vendor/bundle/gems/celluloid-0.16.0/lib/celluloid/cell.rb:71:in `block in task'
	from vendor/bundle/gems/celluloid-0.16.0/lib/celluloid/actor.rb:357:in `block in task'
	from vendor/bundle/gems/celluloid-0.16.0/lib/celluloid/tasks.rb:57:in `block in initialize'
	from vendor/bundle/gems/celluloid-0.16.0/lib/celluloid/tasks/task_fiber.rb:15:in `block in create'
	from (celluloid):0:in `remote procedure call'
	from vendor/bundle/gems/celluloid-0.16.0/lib/celluloid/calls.rb:92:in `value'
	from vendor/bundle/gems/celluloid-0.16.0/lib/celluloid/proxies/sync_proxy.rb:33:in `method_missing'
	from vendor/bundle/gems/invoker-1.3.0/lib/invoker/power/powerup.rb:17:in `block in run'
	from vendor/bundle/bundler/gems/eventmachine-4d53154a9ea4/lib/eventmachine.rb:187:in `call'
	from vendor/bundle/bundler/gems/eventmachine-4d53154a9ea4/lib/eventmachine.rb:187:in `run_machine'
	from vendor/bundle/bundler/gems/eventmachine-4d53154a9ea4/lib/eventmachine.rb:187:in `run'
	from vendor/bundle/gems/invoker-1.3.0/lib/invoker/power/powerup.rb:13:in `run'
	from vendor/bundle/gems/invoker-1.3.0/lib/invoker/power/powerup.rb:7:in `block in fork_and_start'
	from vendor/bundle/gems/invoker-1.3.0/lib/invoker/power/powerup.rb:7:in `fork'
	from vendor/bundle/gems/invoker-1.3.0/lib/invoker/power/powerup.rb:7:in `fork_and_start'
	from vendor/bundle/gems/invoker-1.3.0/lib/invoker/process_manager.rb:72:in `run_power_server'
	from vendor/bundle/gems/invoker-1.3.0/lib/invoker/commander.rb:39:in `start_manager'
	from vendor/bundle/gems/invoker-1.3.0/lib/invoker/cli.rb:46:in `start'
	from vendor/bundle/gems/thor-0.19.1/lib/thor/command.rb:27:in `run'
	from vendor/bundle/gems/thor-0.19.1/lib/thor/invocation.rb:126:in `invoke_command'
	from vendor/bundle/gems/thor-0.19.1/lib/thor.rb:359:in `dispatch'
	from vendor/bundle/gems/thor-0.19.1/lib/thor/base.rb:440:in `start'
	from vendor/bundle/gems/invoker-1.3.0/lib/invoker/cli.rb:12:in `start'
	from vendor/bundle/gems/invoker-1.3.0/bin/invoker:7:in `<top (required)>'
	from ./bin/invoker:16:in `load'
	from ./bin/invoker:16:in `<main>'
```
@pda
Copy link
Author

pda commented Feb 6, 2015

Nice, thanks again for your efforts @ioquatix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@pda @ioquatix @petergoldstein