perplexes / m2r

Mongrel2 Connection Adapter - Ruby Encrusted Steel-Reinforced Fist
MIT License
90 stars 11 forks source link

Release #29

Closed mostlyobvious closed 11 years ago

mostlyobvious commented 12 years ago

What do you think about releasing some pre version to rubygems with current state?

paneq commented 12 years ago

connection = M2R::Connection.new(options[:sender_id], options[:recv_addr], options[:send_addr])

This line from handler.rb no longer works as it was changed to Connection.for which means we have no idea that our rack handler is broken which means we do not have enough tests to even detect it currently. +1 for release from me when we catch up a little bit on testing.

mostlyobvious commented 12 years ago

I thought about doing release in 0.x version. As stated in semver:

Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.

Not sure why someone tagged it as 1.0.

+1 for more testing.

paneq commented 12 years ago

Didn't know that 0.* can still break anything so I started tagging with 1.0 as we actually did break the api.

mostlyobvious commented 12 years ago

Problem is, we didn't advertise as semver before. I don't want to break existing ~>. Maybe this isn't a problem though.

paneq commented 12 years ago

I don't see a problem. Why not release 1.0.0 ?

mostlyobvious commented 12 years ago

Because of breaking change version increments. I wanted some non-constraining release (in terms of public api) to check whether it's good enough for potential use cases.

paneq commented 12 years ago

There is no easy solution I guess. I would start by releasing 0.1. If anyone had ~> 0.0.3 this new release will not be installed. For ~> 0.0 the update would be installed but I guess no one expected stability from such early version. And I can't imagine anyone putting such statement in Gemfile :). Besides it was installed less than 1.5K times only: https://rubygems.org/gems/m2r .

paneq commented 12 years ago

What more do we need to have release ? One acceptance test ? What tooling should be used for such test in your opinion ?

mostlyobvious commented 12 years ago

Acceptance test for full-stack rack adapter scenario will be fine. Also another one for plain handler. I don't think that more than http client library is needed like net/http or HttpClient.

paneq commented 12 years ago

But should we run rack adapter and mongrel2 as separate processes during such acceptance test ? I agree about just using client library for testing it.

mostlyobvious commented 12 years ago

Yes, there should be separate process. Let citrus test case guide you: https://github.com/pawelpacana/citrus/blob/master/test/support/acceptance_test_case.rb

paneq commented 12 years ago

I will use bbq and capybara-mechanize.

paneq commented 12 years ago

Take a look at #36 . Marking parts of the api as private or public is the last thing we should do before the release, right?

paneq commented 12 years ago

@pawelpacana Documentation is improved. Do you think we can release a new version ?

mostlyobvious commented 12 years ago

Make acceptance tests pass on CI and push 0.1.0.

paneq commented 11 years ago

We need to figure out why rbx fails and we can release new version: https://travis-ci.org/#!/perplexes/m2r/jobs/2402260

paneq commented 11 years ago

Done! :)