Tork 18.0.0

Ruby
#1

Tork - Test with fork - https://github.com/sunaku/tork#readme

___ /___________ /__
_ _/ __ \ / //
/ // // / / / ,
_/_// //|_
>>>------>

What is it?

Tork runs your tests as they change, in parallel:

  1. Absorbs test execution overhead into a master process.

  2. Forks to inherit overhead and run test files in parallel.

  3. Avoids running unchanged tests inside changed test files.

What is new?

Version 18.0.0 (2012-02-06)

Alert:

  • RSpec 2.8.0 and older contain a bug where a nonzero
    exit status (caused by an uncaught exception) is overridden
    by RSpec’s Kernel#at_exit handler to be zero, thereby
    falsely indicating that a spec had passed. This patch fixes the
    problem. Thanks to Gumaro Melendez for reporting this issue.

Major:

  • Dropped first parameter to Tork::Config::test_file_globbers.

  • GH-31: tork-master now emits separate exit code and info.
    Update your Tork::Config::test_event_hooks accordingly.

  • tork/server: switch from modules to class inheritance.

  • tork/config: switch to Struct to prevent misspellings.

Minor:

  • tork-driver now recursively expands dependent test files while
    globbing.

  • Extracted bookkeeping stuff from tork-driver into tork-engine
    component.

Other:

  • tork/config: do not reabsorb when .tork.rb
    changes. Since the configuration is loaded in
    multiple processes, it is difficult to reload
    the configuration on the fly without adding
    significant complexity to Tork. Instead, it’s
    easier to accept the limitation that you must
    restart Tork if you change your configuration.

  • GH-29: bump guard version requirement to v1 series.

  • Improve documentation; revise markdown; clean up.

#2

You have faster major version release cycle than Chrome…

2012/2/6, Suraj N. Kurapati [email protected]:

#3

Am 06.02.2012 22:07, schrieb Bartosz Dziewoński:

You have faster major version release cycle than Chrome…

I was hoping to see version 100.0.0 this year’s christmas.

Valete,
Marvin

#4

Marvin Gülker wrote in post #1044440:

Am 06.02.2012 22:07, schrieb Bartosz Dziewoński:

You have faster major version release cycle than Chrome…

I was hoping to see version 100.0.0 this year’s christmas.

Hehe :slight_smile:

I’m just following RubyGems’ Rational Versioning Policy:

http://docs.rubygems.org/read/chapter/7

Cheers.

#5

On Feb 6, 2012, at 21:41 , Nikolai W. wrote:

But perhaps you could rationalize your release cycles.

Suraj writes open source software and is free to do so in any way he
wants. If you don’t like it or the way he does it then don’t use his
software. But he doesn’t have to explain himself to you or anyone else.
Personally I think the way he writes software makes it less usable, but
he says that this works well for him and that’s really all he needs.
More power to him.

#6

On Tue, Feb 7, 2012 at 10:11, Ryan D. [email protected]
wrote:

I’m just following RubyGems’ Rational Versioning Policy:

http://docs.rubygems.org/read/chapter/7

But perhaps you could rationalize your release cycles.

Suraj writes open source software and is free to do so in any way he wants. If
you don’t like it or the way he does it then don’t use his software. But he
doesn’t have to explain himself to you or anyone else. Personally I think the way
he writes software makes it less usable, but he says that this works well for him
and that’s really all he needs. More power to him.

I don’t understand what you’re getting at. Do you feel that I wrote
something untoward? If so, what? If you felt the need to defend
Suraj, are you assuming that he cannot do so himself? And, if you
must write responses such as this, could you please do it in a
pleasant and constructive manner? Not everyone is looking for a fight
on this mailing list and considering that most of my spare energy is
currently going towards taking care of a displeased baby, I really
don’t have any left over for people like you trying to pick a fight.

I commented on this subject because I felt that Suraj is making it
very hard to use his software, as it’s constantly changing and its
thus nearly impossible to gain any of the benefits that come with
updates. I didn’t feel that I needed to spend too many words
explaining this, as, as you yourself point out, I’m sure he’s well
aware of this himself.

But, if need be, I think, Suraj, that you could make it a lot easier
for your users to use your software if you didn’t make, what I would
consider, minor changes to external interfaces, so easily. And if you
do, collect more of them between mayor releases so that your users
don’t have to look through a change log every week to get up to speed
with the latest release. Please consider this comment as constructive
criticism.

#7

On Tue, Feb 7, 2012 at 02:36, Suraj K. [email protected] wrote:

Marvin Gülker wrote in post #1044440:

Am 06.02.2012 22:07, schrieb Bartosz Dziewoński:

You have faster major version release cycle than Chrome…

I was hoping to see version 100.0.0 this year’s christmas.

I’m just following RubyGems’ Rational Versioning Policy:

http://docs.rubygems.org/read/chapter/7

But perhaps you could rationalize your release cycles.

#8

On Feb 7, 2012, at 01:39 , Nikolai W. wrote:

I commented on this subject because I felt that Suraj is making it very hard to
use his software

He absolutely is and we’re in complete agreement there… but that’s
entirely his prerogative.

#9

On Tuesday, February 7, 2012 1:11:25 AM UTC-8, Ryan D. wrote:

I think the way he writes software makes it less usable, but he
says that this works well for him and that’s really all he needs.

The way I write software hinders usability? Don’t you mean the
way I release it?

#10

[Disclaimer: I’m not using this tool. Outsider’s perspective below:]

2012/2/8 Suraj K. [email protected]:

Since you must actively choose to upgrade to a new version, it
should be reasonable for me to assume that you would check the
release notes for breaking changes (which are indicated by a major
version number bump, by the way) and update your usage accordingly.

I mean no offense here; but when every other release is a major
version bump, these sort of lose their importance IMO. It’s easy (and
IMO also reasonable) to assume that if you released v17 a week ago,
and v16 a week before that, etc., then much couldn’t have changed
between them - just like you may not even notice (coming back to my
original, snarky, I admit, remark) Chrome updating itself to another
major version, because nothing on the outside has really changed.

– Matma R.

#11

On Thu 09 Feb 2012 03:51:29 AM PST, Bartosz Dziewoński wrote:

but when every other release is a major version bump, these sort
of lose their importance IMO. It’s easy (and IMO also reasonable)
to assume that if you released v17 a week ago, and v16 a week
before that, etc., then much couldn’t have changed between them -
just like you may not even notice (coming back to my original,
snarky, I admit, remark) Chrome updating itself to another major
version, because nothing on the outside has really changed.

You seem to expect version numbers to convey the importance of
changes in addition to the kinds of changes included in a release.

That is not the case under the RubyGems Rational Versioning Policy,
where version bumps only indicate the kinds of changes involved:

  • major bump => incompatible changes
  • minor bump => compatible changes (new functionality)
  • patch bump => compatible changes (same functionality)

Importance is subjective whereas thinking of changes in terms of
compatibility is objective: it either breaks your stuff or doesn’t.

And that is why I stick to the RubyGems Rational Versioning Policy;
it makes the release process objective and mechanical, which, as a
programmer, I’m sure you can appreciate. :wink:

#12

Whoops, sorry for the late response folks. (Although I enabled
notifications for this thread on RubyForum, I didn’t receive any!)

Nikolai W. wrote in post #1044504:

On Tue, Feb 7, 2012 at 10:11, Ryan D. wrote:

I’m just following RubyGems’ Rational Versioning Policy:
http://docs.rubygems.org/read/chapter/7

But perhaps you could rationalize your release cycles.

Suraj writes open source software and is free to do so in any way
he wants.

Technically, I agree with Ryan; see my rationale towards the end.

I felt that Suraj is making it very hard to use his software, as
it’s constantly changing and its thus nearly impossible to gain
any of the benefits that come with updates.

Do you find my release notes (and ruby-talk announcements thereof)
lacking? How might I change them to better convey the benefits?

you could make it a lot easier for your users to use your software
if you didn’t make, what I would consider, minor changes to
external interfaces, so easily.

As a perfectionist, it’s hard for me to not make such changes. :slight_smile: I
feel that even the smallest details in a system contribute to the
overall user experience, so it’s important for me to get it right.

Unfortunately, I do this by iterating (experiment and reflect) so,
as a consumer, you may rightfully feel annoyed by the process. It
just comes with the territory, I suppose; one trade-off among many.

And if you do, collect more of them between mayor releases so that
your users don’t have to look through a change log every week to
get up to speed with the latest release. Please consider this
comment as constructive criticism.

Understood. I thought “release early, release often” was the modus
operandi of open source software developers, and acted accordingly.

In my view, consumers of libraries and tools distributed as RubyGems
are insulated from the ceaseless churn of releases and version bumps
by Bundler and friends, or even ye olde gem(name, constraint) calls.

Since you must actively choose to upgrade to a new version, it
should be reasonable for me to assume that you would check the
release notes for breaking changes (which are indicated by a major
version number bump, by the way) and update your usage accordingly.

Cheers.

#13

On Wed, Feb 8, 2012 at 19:22, Suraj N. Kurapati [email protected]
wrote:

  • major bump => incompatible changes

This is an important change insofar as you have to be very aware of it.
The
point being made is, I believe, that there shouldn’t be 20
interface-breaking changes in like one year.

#14

On Feb 8, 2012, at 08:19 , Suraj K. wrote:

On Tuesday, February 7, 2012 1:11:25 AM UTC-8, Ryan D. wrote:

I think the way he writes software makes it less usable, but he
says that this works well for him and that’s really all he needs.

The way I write software hinders usability? Don’t you mean the
way I release it?

Actually no. Your releases are great. I think you’re hindered by your
API fluctuating too heavily and it suggests to me that you’re not
planning on your design enough up front. I’m all for API evolution, but
it needs to be balanced against usability. If it fluctuates too much
over a short period of time, it isn’t as usable as the users can’t keep
up with you. Either they’re going to stay with an old version forever or
they’re going to leave the library for something more predictable.

#15

On Thu 09 Feb 2012 05:33:40 AM PST, Adam P. wrote:

On Wed, Feb 8, 2012 at 19:22, Suraj N. Kurapati wrote:

  • major bump => incompatible changes

This is an important change insofar as you have to be very aware
of it.

Agreed; that’s why there are release notes (see HISTORY.markdown).

The point being made is, I believe, that there shouldn’t be 20
interface-breaking changes in like one year.

Why not? You only need to become aware of the incompatible changes
(by reading the release notes) involved iff you want to upgrade!

I would rather let my software grow organically than artificially
direct its growth (either by delaying releases or by pre-planning
major milestones) just to lessen its users’ burden of upgrading.

#16

On Thu 09 Feb 2012 07:18:49 AM PST, Ryan D. wrote:

On Feb 8, 2012, at 08:19 , Suraj K. wrote:

On Tuesday, February 7, 2012 1:11:25 AM UTC-8, Ryan D. wrote:

the way he writes software makes it less usable

Don’t you mean the way I release it?

Actually no. Your releases are great. I think you’re hindered by
your API fluctuating too heavily and it suggests to me that
you’re not planning on your design enough up front.

Indeed, I am just going with the flow.

I’m all for API evolution, but it needs to be balanced against
usability. If it fluctuates too much over a short period of time,
it isn’t as usable as the users can’t keep up with you. Either
they’re going to stay with an old version forever or they’re going
to leave the library for something more predictable.

Fair enough, thanks for explaining.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs