[Cucumber:1528] use_transactional_fixtures -> NoMethodError in Cucumber 0.3.104

Post by QuBiT
Hi,
after upgrading my gems
"gem update" "gem cleanup"
having only cucumber version 0.3.104 installed and running "rake
features"
undefined method 'use_transactional_fixtures' for
Cucumber::Rails::Module (NoMethodError).

This changed in 0.3.102 and 0.3.103
The API to turn on and off transactions has changed.

Run script/generate cucumber

This will generate a new features/support/env.rb file that uses the new API.
(You'll see how the API is different when you do that).

Every now and then there are slight API changes that require a regeneration
of the env.rb file, and I realise
it can be hard to remember to do this after an upgrade, even when
History.txt mentions it explicitly.

Should I add a post-install message for the gem reminding Rails users to run
script/generate cucumber?

Aslak

Post by QuBiT
I have checked my env.rb in features/support and I have this lines in
ENV["RAILS_ENV"] ||= "test"
require File.expand_path(File.dirname(FILE) + '/../../config/
environment')
require 'cucumber/rails/world'
require 'cucumber/formatter/unicode' # Comment out this line if you
don't want Cucumber Unicode support
Cucumber::Rails.use_transactional_fixtures
Downgrading (uninstalling 0.3.104 and reinstalling 0.3.101) works and
running "rake features" does not throw an error.
So PLEASE help me to get rid of this error.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Cukes" group.
To post to this group, send email to cukes-/***@public.gmane.org
To unsubscribe from this group, send email to cukes+unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/cukes?hl=en
-~----------~----~----~----~------~----~------~--~---

QuBiT

2009-09-28 10:03:33 UTC

Hi thx for this hint.

Until today, I've never read the History.txt, just used the Wiki and I
found no Link in the Wiki (main page or troubleshooting page, or some
other useful page) that there is a History.txt.

So maybe just change the Wiki and add a Note that such issues can be
found in the History.txt.

Adding a post-install message could be useful (but only if someone
reads them ^^), but I think a better Wiki page (thought that this is
the main documentation source for cucumber) would be enough.

Cheers QuBiT

This changed in 0.3.102 and 0.3.103
The API to turn on and off transactions has changed.
Run script/generate cucumber
This will generate a new features/support/env.rb file that uses the new API.
(You'll see how the API is different when you do that).
Every now and then there are slight API changes that require a regeneration
of the env.rb file, and I realise
it can be hard to remember to do this after an upgrade, even when
History.txt mentions it explicitly.
Should I add a post-install message for the gem reminding Rails users to run
script/generate cucumber?
Aslak

aslak hellesoy

2009-09-28 10:18:10 UTC

Post by QuBiT
Hi thx for this hint.
Until today, I've never read the History.txt,

Sounds like you like living dangerously.

just used the Wiki and I

Post by QuBiT
found no Link in the Wiki (main page or troubleshooting page, or some
other useful page) that there is a History.txt.

All good software has a change log that is part of the release package. It's
usually called CHANGES, History.txt or something similar. If I upgrade a
software package and something goes wrong, this is the first place I go to
check if I missed something.

I recommend everyone else does the same, whether it's cucumber or something
else.

Post by QuBiT
So maybe just change the Wiki and add a Note that such issues can be
found in the History.txt.

Added: http://wiki.github.com/aslakhellesoy/cucumber/upgrading

Post by QuBiT
Adding a post-install message could be useful (but only if someone
reads them ^^),

People who upgrade without reading History.txt OR a post install message
(which I will add in the next release) are sloppy. There is nothing I can do
to help in that case. ;-)

Aslak

but I think a better Wiki page (thought that this is

Post by QuBiT
the main documentation source for cucumber) would be enough.
Cheers QuBiT

This changed in 0.3.102 and 0.3.103
The API to turn on and off transactions has changed.
Run script/generate cucumber
This will generate a new features/support/env.rb file that uses the new

API.

Post by aslak hellesoy
(You'll see how the API is different when you do that).
Every now and then there are slight API changes that require a

regeneration

Post by aslak hellesoy
of the env.rb file, and I realise
it can be hard to remember to do this after an upgrade, even when
History.txt mentions it explicitly.
Should I add a post-install message for the gem reminding Rails users to

run

Post by aslak hellesoy
script/generate cucumber?
Aslak

Jim Meyer

2009-09-28 14:16:04 UTC

Post by aslak hellesoy
People who upgrade without reading History.txt OR a post install message
(which I will add in the next release) are sloppy. There is nothing I
can do to help in that case. ;-)

There is *one* thing we could do better:

Add a comment to the top of env.rb which notes the version of cucumber
which installed it. At the very least, it will make obvious how far
apart the env.rb and running cucumber are; if we wanted to, we could
also have cucumber notice this comment (if present) and warn when
running a particularly old configuration.

--j

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Cukes" group.
To post to this group, send email to cukes-/***@public.gmane.org
To unsubscribe from this group, send email to cukes+unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/cukes?hl=en
-~----------~----~----~----~------~----~------~--~---

Assaf Arkin

2009-09-28 18:23:30 UTC

Post by QuBiT
Hi thx for this hint.
Until today, I've never read the History.txt,

Sounds like you like living dangerously.

Is there continuous integration for Cucumber itself? Are releases tested
before making their way out to Rubyforge?

It seems that every release something breaks in an annoying spend an hour
figuring out why way. And I'm not talking about changes covered by
history.txt, well they are, but in the history.txt of a follow-up release
which fixes these bugs (and too often introduces new ones).

I don't see much correlation between reading history.txt and avoiding my
setup from breaking. Merely allowing gem update to download a new version of
Cucumber is living dangerously. Any plans on dampening the rate of
regressions?

Assaf
*
*

Post by aslak hellesoy
just used the Wiki and I

Post by QuBiT
found no Link in the Wiki (main page or troubleshooting page, or some
other useful page) that there is a History.txt.

All good software has a change log that is part of the release package.
It's usually called CHANGES, History.txt or something similar. If I upgrade
a software package and something goes wrong, this is the first place I go to
check if I missed something.
I recommend everyone else does the same, whether it's cucumber or something
else.

Post by QuBiT
So maybe just change the Wiki and add a Note that such issues can be
found in the History.txt.

Added: http://wiki.github.com/aslakhellesoy/cucumber/upgrading

Post by QuBiT
Adding a post-install message could be useful (but only if someone
reads them ^^),

People who upgrade without reading History.txt OR a post install message
(which I will add in the next release) are sloppy. There is nothing I can do
to help in that case. ;-)
Aslak
but I think a better Wiki page (thought that this is

Post by QuBiT
the main documentation source for cucumber) would be enough.
Cheers QuBiT

This changed in 0.3.102 and 0.3.103
The API to turn on and off transactions has changed.
Run script/generate cucumber
This will generate a new features/support/env.rb file that uses the new

API.

Post by aslak hellesoy
(You'll see how the API is different when you do that).
Every now and then there are slight API changes that require a

regeneration

run

Post by aslak hellesoy
script/generate cucumber?
Aslak

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Cukes" group.
To post to this group, send email to cukes-/***@public.gmane.org
To unsubscribe from this group, send email to cukes+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/cukes?hl=en
-~----------~----~----~----~------~----~------~--~---

aslak hellesoy

2009-09-28 19:34:25 UTC

Post by QuBiT
Hi thx for this hint.
Until today, I've never read the History.txt,

Sounds like you like living dangerously.

Is there continuous integration for Cucumber itself?

Currently not. Nobody has offered to set up a server, but I would gladly
accept if someone did. I would need shell access so I can log in and install
new gems etc.

Post by Assaf Arkin
Are releases tested before making their way out to Rubyforge?

Of course. Cucumber has an extensive test suite in both Cucumber and RSpec.
There is also a test suite in the cucumber_rails project that verifies that
Cucumber works with the past 6 or so Rails versions. In addition to this
there is Cuke4Duke, which pokes Cucumber from another angle, namely through
JRuby and half a dozen JVM languages. All of these suites are run before
each release. I also run the Cucumber+RSpec suite before each commit. No
commits are made if there is a single failing scenario or spec.

Post by Assaf Arkin
It seems that every release something breaks in an annoying spend an
hour figuring out why way. And I'm not talking about changes covered by
history.txt, well they are, but in the history.txt of a follow-up release
which fixes these bugs (and too often introduces new ones).

Can you give some examples of regressions that you have seen recently? How
do you define regression? (For example, do you consider a bug in a new
feature a regression?)

Post by Assaf Arkin
I don't see much correlation between reading history.txt and avoiding my
setup from breaking. Merely allowing gem update to download a new version of
Cucumber is living dangerously. Any plans on dampening the rate of
regressions?

In order to reduce the rate of regressions I have to know what it is today
so that I can measure it in the future. In your opinion, what is the current
rate of regression? What's a good measure of regression rate?

Aslak

Assaf

Post by Assaf Arkin
*
*

Post by aslak hellesoy
just used the Wiki and I

Post by QuBiT
found no Link in the Wiki (main page or troubleshooting page, or some
other useful page) that there is a History.txt.

All good software has a change log that is part of the release package.
It's usually called CHANGES, History.txt or something similar. If I upgrade
a software package and something goes wrong, this is the first place I go to
check if I missed something.
I recommend everyone else does the same, whether it's cucumber or
something else.

Post by QuBiT
So maybe just change the Wiki and add a Note that such issues can be
found in the History.txt.

Added: http://wiki.github.com/aslakhellesoy/cucumber/upgrading

Post by QuBiT
Adding a post-install message could be useful (but only if someone
reads them ^^),

People who upgrade without reading History.txt OR a post install message
(which I will add in the next release) are sloppy. There is nothing I can do
to help in that case. ;-)
Aslak
but I think a better Wiki page (thought that this is

Post by QuBiT
the main documentation source for cucumber) would be enough.
Cheers QuBiT

This changed in 0.3.102 and 0.3.103
The API to turn on and off transactions has changed.
Run script/generate cucumber
This will generate a new features/support/env.rb file that uses the new

API.

Post by aslak hellesoy
(You'll see how the API is different when you do that).
Every now and then there are slight API changes that require a

regeneration

to run

Post by aslak hellesoy
script/generate cucumber?
Aslak

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Cukes" group.
To post to this group, send email to cukes-/***@public.gmane.org
To unsubscribe from this group, send email to cukes+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/cukes?hl=en
-~----------~----~----~----~------~----~------~--~---

Ben Mabey

2009-09-28 21:02:37 UTC

On Mon, Sep 28, 2009 at 3:18 AM, aslak hellesoy
Hi thx for this hint.
Until today, I've never read the History.txt,
Sounds like you like living dangerously.
Is there continuous integration for Cucumber itself?
Currently not. Nobody has offered to set up a server, but I would
gladly accept if someone did. I would need shell access so I can log
in and install new gems etc.

We could look into RunCodeRun[1]. I'm using it on some other open
source projects with good success. They allow for Ruby 1.9 and other
ruby versions. However, I'm not sure if they allow for different ruby
versions in the same build process, which is what we would want to do to
make the build really thorough. The nice think about RunCodeRun is that
if we can get it to work then anyone who forks Cucumber can get there
own build without any effort IIRC.

Aasaf, would that be something you would be interested
investigating/setting up for us? We would be most appreciative for the
help.

Thanks,
Ben

1. http://runcoderun.com/

Are releases tested before making their way out to Rubyforge?
Of course. Cucumber has an extensive test suite in both Cucumber and
RSpec. There is also a test suite in the cucumber_rails project that
verifies that Cucumber works with the past 6 or so Rails versions. In
addition to this there is Cuke4Duke, which pokes Cucumber from another
angle, namely through JRuby and half a dozen JVM languages. All of
these suites are run before each release. I also run the
Cucumber+RSpec suite before each commit. No commits are made if there
is a single failing scenario or spec.
It seems that every release something breaks in an annoying –
spend an hour figuring out why – way. And I'm not talking about
changes covered by history.txt, well they are, but in the
history.txt of a follow-up release which fixes these bugs (and too
often introduces new ones).
Can you give some examples of regressions that you have seen recently?
How do you define regression? (For example, do you consider a bug in a
new feature a regression?)
I don't see much correlation between reading history.txt and
avoiding my setup from breaking. Merely allowing gem update to
download a new version of Cucumber is living dangerously. Any
plans on dampening the rate of regressions?
In order to reduce the rate of regressions I have to know what it is
today so that I can measure it in the future. In your opinion, what is
the current rate of regression? What's a good measure of regression rate?
Aslak
Assaf
/
/
just used the Wiki and I
found no Link in the Wiki (main page or troubleshooting
page, or some
other useful page) that there is a History.txt.
All good software has a change log that is part of the release
package. It's usually called CHANGES, History.txt or something
similar. If I upgrade a software package and something goes
wrong, this is the first place I go to check if I missed
something.
I recommend everyone else does the same, whether it's cucumber
or something else.
So maybe just change the Wiki and add a Note that such
issues can be
found in the History.txt.
Added: http://wiki.github.com/aslakhellesoy/cucumber/upgrading
Adding a post-install message could be useful (but only if someone
reads them ^^),
People who upgrade without reading History.txt OR a post
install message (which I will add in the next release) are
sloppy. There is nothing I can do to help in that case. ;-)
Aslak
but I think a better Wiki page (thought that this is
the main documentation source for cucumber) would be enough.
Cheers QuBiT
On 28 Sep., 11:30, aslak hellesoy

On Mon, Sep 28, 2009 at 11:12 AM, QuBiT

Post by QuBiT
Hi,
after upgrading my gems
"gem update" "gem cleanup"
having only cucumber version 0.3.104 installed and

running "rake

Post by QuBiT
features"
undefined method 'use_transactional_fixtures' for
Cucumber::Rails::Module (NoMethodError).

This changed in 0.3.102 and 0.3.103
The API to turn on and off transactions has changed.
Run script/generate cucumber
This will generate a new features/support/env.rb file

that uses the new API.

(You'll see how the API is different when you do that).
Every now and then there are slight API changes that

require a regeneration

of the env.rb file, and I realise
it can be hard to remember to do this after an upgrade,

even when

History.txt mentions it explicitly.
Should I add a post-install message for the gem

reminding Rails users to run

script/generate cucumber?
Aslak

Post by QuBiT
I have checked my env.rb in features/support and I

have this lines in

Post by QuBiT
ENV["RAILS_ENV"] ||= "test"
require File.expand_path(File.dirname(FILE) +

'/../../config/

Post by QuBiT
environment')
require 'cucumber/rails/world'
require 'cucumber/formatter/unicode' # Comment out

this line if you

Post by QuBiT
don't want Cucumber Unicode support
Cucumber::Rails.use_transactional_fixtures
Downgrading (uninstalling 0.3.104 and reinstalling

0.3.101) works and

Post by QuBiT
running "rake features" does not throw an error.
So PLEASE help me to get rid of this error.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Cukes" group.
To post to this group, send email to cukes-/***@public.gmane.org
To unsubscribe from this group, send email to cukes+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/cukes?hl=en
-~----------~----~----~----~------~----~------~--~---

Assaf Arkin

2009-09-29 00:27:44 UTC

On Mon, Sep 28, 2009 at 12:34 PM, aslak hellesoy

Post by QuBiT
Hi thx for this hint.
Until today, I've never read the History.txt,

Sounds like you like living dangerously.

Is there continuous integration for Cucumber itself?

Currently not. Nobody has offered to set up a server, but I would gladly
accept if someone did. I would need shell access so I can log in and install
new gems etc.

Post by Assaf Arkin
Are releases tested before making their way out to Rubyforge?

That's testing that "things we thought could go wrong, don't go wrong".
Software has a way of breaking in unexpected ways. Friendly testing is never
enough, major changes have to go out to people to poke and prod them for a
while, so the test suite is complete enough to certify a release.

Can you give some examples of regressions that you have seen recently? How
do you define regression? (For example, do you consider a bug in a new
feature a regression?)

Regression: anything that breaks when I gem update cucumber. It obviously
does not include new features I haven't used yet.

Going from 100 to 104:
- lib/cucumber/formatter/html.rb requires ruby-debug
- Gracefully handle cases when optional regexp groups are not matched.
- Added back a way to globally turn off transactions.
- Renamed @allow_rescue tag to @allow-rescue.
- The Cucumber::Rails.bypass_rescue no longer exists. Errors will always
bubble up, unless you use the new @allow_rescue tag.

I am counting changes to allow_rescue because those could have been handled
much more gracefully by deprecating the old behavior for several releases,
then making it obsolete.

I do one update that breaks email_spec (regexp bug), and a follow-up update
that fixes that bug, but introduces another breakage. So going from 101 to
104, 2 out of 3 upgrades were unusable without patches.

Or say I gem update so I can test out the new awesome transform feature.
Should only take five minutes to give it a try, right? 30 minutes later I'm
done figuring out all the scenarios that need @allow_rescue. Classic Yak
shaving.

Assaf

Post by aslak hellesoy
Aslak
Assaf

Post by Assaf Arkin
*
*

Post by aslak hellesoy
just used the Wiki and I

Post by QuBiT
found no Link in the Wiki (main page or troubleshooting page, or some
other useful page) that there is a History.txt.

All good software has a change log that is part of the release package.
It's usually called CHANGES, History.txt or something similar. If I upgrade
a software package and something goes wrong, this is the first place I go to
check if I missed something.
I recommend everyone else does the same, whether it's cucumber or
something else.

Post by QuBiT
So maybe just change the Wiki and add a Note that such issues can be
found in the History.txt.

Added: http://wiki.github.com/aslakhellesoy/cucumber/upgrading

Post by QuBiT
Adding a post-install message could be useful (but only if someone
reads them ^^),

People who upgrade without reading History.txt OR a post install message
(which I will add in the next release) are sloppy. There is nothing I can do
to help in that case. ;-)
Aslak
but I think a better Wiki page (thought that this is

Post by QuBiT
the main documentation source for cucumber) would be enough.
Cheers QuBiT

This changed in 0.3.102 and 0.3.103
The API to turn on and off transactions has changed.
Run script/generate cucumber
This will generate a new features/support/env.rb file that uses the

new API.

Post by aslak hellesoy
(You'll see how the API is different when you do that).
Every now and then there are slight API changes that require a

regeneration

to run

Post by aslak hellesoy
script/generate cucumber?
Aslak

Post by QuBiT
I have checked my env.rb in features/support and I have this lines

Post by QuBiT
ENV["RAILS_ENV"] ||= "test"
require File.expand_path(File.dirname(FILE) + '/../../config/
environment')
require 'cucumber/rails/world'
require 'cucumber/formatter/unicode' # Comment out this line if you
don't want Cucumber Unicode support
Cucumber::Rails.use_transactional_fixtures
Downgrading (uninstalling 0.3.104 and reinstalling 0.3.101) works

and

Post by QuBiT
running "rake features" does not throw an error.
So PLEASE help me to get rid of this error.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Cukes" group.
To post to this group, send email to cukes-/***@public.gmane.org
To unsubscribe from this group, send email to cukes+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/cukes?hl=en
-~----------~----~----~----~------~----~------~--~---

Ben Mabey

2009-09-29 02:48:41 UTC

Post by Assaf Arkin
On Mon, Sep 28, 2009 at 12:34 PM, aslak hellesoy
On Mon, Sep 28, 2009 at 3:18 AM, aslak hellesoy
On Mon, Sep 28, 2009 at 12:03 PM, QuBiT
Hi thx for this hint.
Until today, I've never read the History.txt,
Sounds like you like living dangerously.
Is there continuous integration for Cucumber itself?
Currently not. Nobody has offered to set up a server, but I would
gladly accept if someone did. I would need shell access so I can
log in and install new gems etc.
Are releases tested before making their way out to Rubyforge?
Of course. Cucumber has an extensive test suite in both Cucumber
and RSpec. There is also a test suite in the cucumber_rails
project that verifies that Cucumber works with the past 6 or so
Rails versions. In addition to this there is Cuke4Duke, which
pokes Cucumber from another angle, namely through JRuby and half a
dozen JVM languages. All of these suites are run before each
release. I also run the Cucumber+RSpec suite before each commit.
No commits are made if there is a single failing scenario or spec.
That's testing that "things we thought could go wrong, don't go
wrong". Software has a way of breaking in unexpected ways. Friendly
testing is never enough, major changes have to go out to people to
poke and prod them for a while, so the test suite is complete enough
to certify a release.

We of course try to do some exploratory testing before each release but
due to time constraints it can't be exhaustive. It seems like you are
suggesting having release candidates to have people try out before the
official release. Is that correct? I've seen release candidates work
for larger projects but often ignored for smaller libraries. So I'm not
sure if adding a release candidate cycle would be very beneficial
compared to the additional overhead it would add. If we did move to a
RC cycle would you be willing to do some exploratory testing? Judging
by your frustration of how you have "wasted your time" upgrading
recently I get the impression that you wouldn't. Please correct me if
I'm wrong.

Aslak- it seems like you used to make less frequent releases to
rubyforge in the past and kept most patch releases on Github. Is that
right? One suggestion would be to go back to that and let the releases
sit on github for a while to let them mature. Then if people really
want new features, like the step transforms, they would have to pull it
from github with the understanding that they may have to report a bug
(!!) and work through some rough edges. Just a thought. I kinda think
that would make more people annoyed than happy, but who knows. Does
anyone else on the list have any thoughts on the matter?

-Ben

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Cukes" group.
To post to this group, send email to cukes-/***@public.gmane.org
To unsubscribe from this group, send email to cukes+unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/cukes?hl=en
-~----------~----~----~----~------~----~------~--~---

Assaf Arkin

2009-09-29 05:57:52 UTC

Post by Ben Mabey

It's not a matter of size, it's a matter of maturity. If you're still
ramping up to your first real release, then you'd expect APIs that break
every week, you'd expect Works On My Machine as exit criteria.

If you want people using your product then you need to step it up. For
successful products, maturity tends to correlate with size of the user base.
Deliver something that people can depend on and you'll grow that user base.

Where do you see Cucumber, between rapid exploratory development and a tool
Ruby developers should just use?

Also, Cucumber is a testing tool, bundled with a testing methodology. I have
an expectation that testing tools will follow best practices set up by
other. I expect it to innovate in BDD, but stand on the shoulders of giants
in everything else, specifically proven test practices.

As a test tool what is the message you're sending about the practice of
testing?

Post by Ben Mabey
If we did move to a
RC cycle would you be willing to do some exploratory testing? Judging
by your frustration of how you have "wasted your time" upgrading
recently I get the impression that you wouldn't. Please correct me if
I'm wrong.

If Cucumber got its act together, then yes. I work with RCs, Betas, source
control. I have a high tolerance for pain, and often will trade stability
for new features. The thing is, if I'm getting a new release to test a new
feature that may (or not) be broken *and* I have to fix all my email specs
*and* my CI build system breaks *and* all my rescue tests are broken, then
I'm shaving too many Yaks to test that feature.

If you want more people testing new features, keep them isolated. Do them in
branches, merge with master in a controller manner, so you're getting
feedback on one feature at a time.

Assaf

Post by Ben Mabey
Aslak- it seems like you used to make less frequent releases to
rubyforge in the past and kept most patch releases on Github. Is that
right? One suggestion would be to go back to that and let the releases
sit on github for a while to let them mature. Then if people really
want new features, like the step transforms, they would have to pull it
from github with the understanding that they may have to report a bug
(!!) and work through some rough edges. Just a thought. I kinda think
that would make more people annoyed than happy, but who knows. Does
anyone else on the list have any thoughts on the matter?
-Ben

Matt Wynne

2009-09-29 09:32:19 UTC

Post by Assaf Arkin
- lib/cucumber/formatter/html.rb requires ruby-debug

That's my mistake and should be removed.

cheers,
Matt

http://mattwynne.net
+447974 430184

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Cukes" group.
To post to this group, send email to cukes-/***@public.gmane.org
To unsubscribe from this group, send email to cukes+unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/cukes?hl=en
-~----------~----~----~----~------~----~------~--~---

Matt Southerden

2009-09-29 11:46:04 UTC

Is there a specific way that you are handling version numbering? I
would personally most likely be expecting x.x.x version numbering to
be along the lines of major.minor.maintenance. Where a change to the
maintenance version would not break the api. (Working with gem
versioning, it's common to specify deps something like: gem '~> 1.2.2')

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

Post by Matt Wynne

Post by Assaf Arkin
- lib/cucumber/formatter/html.rb requires ruby-debug

That's my mistake and should be removed.
cheers,
Matt
http://mattwynne.net
+447974 430184

Matt Wynne

2009-09-29 14:56:53 UTC

Post by Matt Southerden
Is there a specific way that you are handling version numbering? I
would personally most likely be expecting x.x.x version numbering to
be along the lines of major.minor.maintenance. Where a change to the
maintenance version would not break the api. (Working with gem
versioning, it's common to specify deps something like: gem '~> 1.2.2')
http://docs.rubygems.org/read/chapter/7

Yep, arguably we could be bumping the minor version a lot more
frequently whenever we introduce a breaking change. Would people find
that more communicative?

cheers,
Matt

http://mattwynne.net
+447974 430184

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Cukes" group.
To post to this group, send email to cukes-/***@public.gmane.org
To unsubscribe from this group, send email to cukes+unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/cukes?hl=en
-~----------~----~----~----~------~----~------~--~---

Assaf Arkin

2009-09-29 17:08:48 UTC

Post by Matt Wynne

Yep, arguably we could be bumping the minor version a lot more
frequently whenever we introduce a breaking change. Would people find
that more communicative?

I think it will go further than that. Merely making a decision about what
goes in each release, and taking into consideration the expectations of
others (as in, following conventions) is an important step to improving
quality of releases.

Assaf

Post by Matt Wynne
cheers,
Matt
http://mattwynne.net
+447974 430184

Jim Meyer

2009-09-29 18:44:35 UTC

Changing the subject line to be reflective of the conversation. =]

Post by Matt Wynne
Yep, arguably we could be bumping the minor version a lot more
frequently whenever we introduce a breaking change. Would people find
that more communicative?
I think it will go further than that. Merely making a decision about
what goes in each release, and taking into consideration the
expectations of others (as in, following conventions) is an important
step to improving quality of releases.

I find myself on both sides of the fence. I've noticed the need to adapt
to a new Cucumber release more often than any other library I'm using,
I've also employed very standard tactics (gem freeze, version lock) to
insulate certain projects from unnecessary pain around upgrading; I
leave a few others unlocked, though, so I'll see problems in a bounded,
non-urgent way.

I think the real question is: what kind of users do we want to attract
to Cucumber at the moment?

If we're working to define what 1.0 needs to be complete, I'd say we
want coders who can cope and help improve the framework either directly
or by engaging with Cuke in its current, rapidly changing state. In that
state, the way releases are working is (imho) just fine; we don't want
it to be smooth quite yet or we'll lull someone into a false sense of
security.

If we've got a clear idea of what 1.0 is, then we should be more focused
about what each release is and pulling in more of the people/projects we
expect to use Cucumber long term. In this state, we want to be more
formal about versioning, and releases should be far more smooth.

--j

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Cukes" group.
To post to this group, send email to cukes-/***@public.gmane.org
To unsubscribe from this group, send email to cukes+unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/cukes?hl=en
-~----------~----~----~----~------~----~------~--~---

Stephen Eley

2009-09-29 20:17:47 UTC

Post by Matt Wynne
Yep, arguably we could be bumping the minor version a lot more
frequently whenever we introduce a breaking change. Would people find
that more communicative?

I would. Or at least, I'd be more comfortable with minor number 11
than I am with maintenance number 104. >8-> At least given the scope
of change that's all fallen under the 0.3 umbrella.

(Just for kicks, I just now did a "git diff v0.3.0 v0.3.104". The
results were...voluminous.) >8->
--
Have Fun,
Steve Eley (sfeley-***@public.gmane.org)
ESCAPE POD - The Science Fiction Podcast Magazine
http://www.escapepod.org

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Cukes" group.
To post to this group, send email to cukes-/***@public.gmane.org
To unsubscribe from this group, send email to cukes+unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/cukes?hl=en
-~----------~----~----~----~------~----~------~--~---

aslak hellesoy

2009-09-29 13:45:03 UTC

On Mon, Sep 28, 2009 at 3:18 AM, aslak hellesoy <

Post by QuBiT
Hi thx for this hint.
Until today, I've never read the History.txt,

Sounds like you like living dangerously.

Is there continuous integration for Cucumber itself?

Currently not. Nobody has offered to set up a server, but I would gladly
accept if someone did. I would need shell access so I can log in and install
new gems etc.

Are releases tested before making their way out to Rubyforge?

Of course. Cucumber has an extensive test suite in both Cucumber and
RSpec. There is also a test suite in the cucumber_rails project that
verifies that Cucumber works with the past 6 or so Rails versions. In
addition to this there is Cuke4Duke, which pokes Cucumber from another
angle, namely through JRuby and half a dozen JVM languages. All of these
suites are run before each release. I also run the Cucumber+RSpec suite
before each commit. No commits are made if there is a single failing
scenario or spec.

It seems that every release something breaks in an annoying spend an
hour figuring out why way. And I'm not talking about changes covered by
history.txt, well they are, but in the history.txt of a follow-up release
which fixes these bugs (and too often introduces new ones).

Can you give some examples of regressions that you have seen recently? How
do you define regression? (For example, do you consider a bug in a new
feature a regression?)

I don't see much correlation between reading history.txt and avoiding my
setup from breaking. Merely allowing gem update to download a new version of
Cucumber is living dangerously. Any plans on dampening the rate of
regressions?

Regression: anything that breaks when I gem update cucumber. It obviously
does not include new features I haven't used yet.
- lib/cucumber/formatter/html.rb requires ruby-debug

This was a classic mistake. Matt had forgotten to take it out while he
refactored the hell out of formatters to enable a more pluggable lifecycle
mechanism. I overlooked it when I merged it in and didn't notice it because
I happened to have ruby-debug installed. This kind of bug is unfortunate,
but almost impossible to pick up automatically. The only thing that can
catch it is eyeballing. Fortunately this kind of oversight is rare.

Aslak: -1

Post by Assaf Arkin
- Gracefully handle cases when optional regexp groups are not matched.

As far as I can tell this is a bug that has existed since the very beginning
of Cucumber. It's just hat nobody has reported until now, because it's a
rare edge case. If this is a regression I must be missing something.

Aslak: +0.5

Post by Assaf Arkin
- Added back a way to globally turn off transactions.

Definitely due to a regression.

Aslak: -1
I decided that aesthetically, a dash looked better than an underscore. I
actually considered keeping suport for both tags. To ensure long term
consistency, that would mean supporting the underscore tag, but issue a
warning. This would require some extra logic, just to deal with that.

Since the rename was done in a release only 2 days after the first tag was
introduced, and since you'd have to read commit logs or History.txt to know
about it in the first place, I assumed this would concern very few people,
and that it was worth it to avoid adding the deprecation logic.

Aslak: -1

Post by Assaf Arkin
- The Cucumber::Rails.bypass_rescue no longer exists. Errors will always

It was a mistake to just remove this.

Post by Assaf Arkin
I am counting changes to allow_rescue because those could have been handled
much more gracefully by deprecating the old behavior for several releases,
then making it obsolete.

Agreed.
Aslak: -1

Post by Assaf Arkin
I do one update that breaks email_spec (regexp bug),

That must be a bug I'm not aware of. Is it in a tracker somewhere? Is this
an email_spec bug or a Cucumber bug?

Aslak: -0

Post by Assaf Arkin
and a follow-up update that fixes that bug, but introduces another
breakage. So going from 101 to 104, 2 out of 3 upgrades were unusable
without patches.

My total score: -3.5. That's a bad score.

I'm sorry you've experienced this much trouble lately. I know it has bitten
a few other people too - especially the changes in rescue and transaction
handling. The past few releases have definitely been under par compared to
previous releases. I'll try to be more careful.

Or say I gem update so I can test out the new awesome transform feature.

Post by Assaf Arkin
Should only take five minutes to give it a try, right? 30 minutes later I'm
shaving.

A while ago I got into the habit of doing release candidates on GitHub
(x.y.z.rc). Would it help to go back to that scheme?

Rubygems 1.3.5 has a new --prerelease switch, which means that it will only
install prerelease gems if you ask for it. I could push prerelease gems
(e.g. 0.4.0.rc1) to gemcutter, allowing people to play with a gem before an
official release is made. The .rc suffix should also make it more clear that
there might be broken stuff in there.

Let me make it clear: Cucumber is in version 0.3.x. In other words, it
hasn't had a major release yet. This means it's still a moving target. If it
wasn't I would have called it 1.0. Some periods are more turbulent than
others. A new turbulence period started about couple of months ago when work
started on the wire protocol, refactorings needed for cuke4duke, new
formatter API etc. We could do without these changes. That would be the same
as stagnation. I would much rather do these big things before a major
release, when people *really* don't expect things to break.

Post by Assaf Arkin
Assaf

Post by aslak hellesoy
Aslak
Assaf

*
*

Post by aslak hellesoy
just used the Wiki and I

Post by QuBiT
found no Link in the Wiki (main page or troubleshooting page, or some
other useful page) that there is a History.txt.

All good software has a change log that is part of the release package.
It's usually called CHANGES, History.txt or something similar. If I upgrade
a software package and something goes wrong, this is the first place I go to
check if I missed something.
I recommend everyone else does the same, whether it's cucumber or
something else.

Post by QuBiT
So maybe just change the Wiki and add a Note that such issues can be
found in the History.txt.

Added: http://wiki.github.com/aslakhellesoy/cucumber/upgrading

Post by QuBiT
Adding a post-install message could be useful (but only if someone
reads them ^^),

People who upgrade without reading History.txt OR a post install message
(which I will add in the next release) are sloppy. There is nothing I can do
to help in that case. ;-)
Aslak
but I think a better Wiki page (thought that this is

Post by QuBiT
the main documentation source for cucumber) would be enough.
Cheers QuBiT

This changed in 0.3.102 and 0.3.103
The API to turn on and off transactions has changed.
Run script/generate cucumber
This will generate a new features/support/env.rb file that uses the

new API.

Post by aslak hellesoy
(You'll see how the API is different when you do that).
Every now and then there are slight API changes that require a

regeneration

to run

Post by aslak hellesoy
script/generate cucumber?
Aslak

Post by QuBiT
I have checked my env.rb in features/support and I have this lines

and

Post by QuBiT
running "rake features" does not throw an error.
So PLEASE help me to get rid of this error.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Cukes" group.
To post to this group, send email to cukes-/***@public.gmane.org
To unsubscribe from this group, send email to cukes+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/cukes?hl=en
-~----------~----~----~----~------~----~------~--~---

Assaf Arkin

2009-09-29 16:48:19 UTC

On Mon, Sep 28, 2009 at 12:34 PM, aslak hellesoy <

On Mon, Sep 28, 2009 at 3:18 AM, aslak hellesoy <

Post by QuBiT
Hi thx for this hint.
Until today, I've never read the History.txt,

Sounds like you like living dangerously.

Is there continuous integration for Cucumber itself?

Currently not. Nobody has offered to set up a server, but I would gladly
accept if someone did. I would need shell access so I can log in and install
new gems etc.

Are releases tested before making their way out to Rubyforge?

Of course. Cucumber has an extensive test suite in both Cucumber and
RSpec. There is also a test suite in the cucumber_rails project that
verifies that Cucumber works with the past 6 or so Rails versions. In
addition to this there is Cuke4Duke, which pokes Cucumber from another
angle, namely through JRuby and half a dozen JVM languages. All of these
suites are run before each release. I also run the Cucumber+RSpec suite
before each commit. No commits are made if there is a single failing
scenario or spec.

Can you give some examples of regressions that you have seen recently?
How do you define regression? (For example, do you consider a bug in a new
feature a regression?)

In order to reduce the rate of regressions I have to know what it is
today so that I can measure it in the future. In your opinion, what is the
current rate of regression? What's a good measure of regression rate?

Regression: anything that breaks when I gem update cucumber. It obviously
does not include new features I haven't used yet.
- lib/cucumber/formatter/html.rb requires ruby-debug

- Gracefully handle cases when optional regexp groups are not matched.

As far as I can tell this is a bug that has existed since the very
beginning of Cucumber. It's just hat nobody has reported until now, because
it's a rare edge case. If this is a regression I must be missing something.

An upgrade from one version of Cucumber to another broke email_specs.rb
(generated by email_spec). The problem was caused by expressions like this:

When /^(?:I|they|"([^"]*?)") opens? the email with subject "([^"]*?)"$/ do
|address, subject|

The version that gracefully handles cases with optional regexp is no longer
broken.

Post by aslak hellesoy
Aslak: +0.5

- Added back a way to globally turn off transactions.

Definitely due to a regression.
Aslak: -1
I decided that aesthetically, a dash looked better than an underscore. I
actually considered keeping suport for both tags. To ensure long term
consistency, that would mean supporting the underscore tag, but issue a
warning. This would require some extra logic, just to deal with that.
Since the rename was done in a release only 2 days after the first tag was
introduced, and since you'd have to read commit logs or History.txt to know
about it in the first place, I assumed this would concern very few people,
and that it was worth it to avoid adding the deprecation logic.
Aslak: -1

- The Cucumber::Rails.bypass_rescue no longer exists. Errors will always

It was a mistake to just remove this.

I am counting changes to allow_rescue because those could have been
handled much more gracefully by deprecating the old behavior for several
releases, then making it obsolete.

Agreed.
Aslak: -1

I do one update that breaks email_spec (regexp bug),

That must be a bug I'm not aware of. Is it in a tracker somewhere? Is this
an email_spec bug or a Cucumber bug?

Optional regexp bug (see above).

Post by aslak hellesoy
Aslak: -0

and a follow-up update that fixes that bug, but introduces another
breakage. So going from 101 to 104, 2 out of 3 upgrades were unusable
without patches.

My total score: -3.5. That's a bad score.

We're dealing with software here. Working software is what happens after we
remove enough bugs. Some days you do nothing but introduce errors and get
around to fixing them. That's why testing is key to what we do.

The issue is not how many bugs you introduce. None? Ten? Hundred a day?
They're all the same. The issue is how you prevent bugs from leaking out to
the world through releases. You can make more bugs a day, and have releases
that are lower on bug count.

Post by aslak hellesoy
I'm sorry you've experienced this much trouble lately. I know it has bitten
a few other people too - especially the changes in rescue and transaction
handling. The past few releases have definitely been under par compared to
previous releases. I'll try to be more careful.
Or say I gem update so I can test out the new awesome transform feature.

Should only take five minutes to give it a try, right? 30 minutes later I'm
shaving.

Release candidate may help, try it out. CI would likely have caught the
ruby-debug issue. Gradually merging changes into master might get people
working directly against source control.

Post by aslak hellesoy
Let me make it clear: Cucumber is in version 0.3.x. In other words, it
hasn't had a major release yet. This means it's still a moving target. If it
wasn't I would have called it 1.0. Some periods are more turbulent than
others. A new turbulence period started about couple of months ago when work
started on the wire protocol, refactorings needed for cuke4duke, new
formatter API etc. We could do without these changes. That would be the same
as stagnation. I would much rather do these big things before a major
release, when people *really* don't expect things to break.

I'm sorry but it's not either or. Many projects have proven that you can
make deep changes and still crank out reliable releases on a schedule. It's
a matter of "do you care enough"?

Assaf

Assaf

Post by aslak hellesoy
Aslak
Assaf

*
*

Post by aslak hellesoy
just used the Wiki and I

Post by QuBiT
found no Link in the Wiki (main page or troubleshooting page, or some
other useful page) that there is a History.txt.

All good software has a change log that is part of the release package.
It's usually called CHANGES, History.txt or something similar. If I upgrade
a software package and something goes wrong, this is the first place I go to
check if I missed something.
I recommend everyone else does the same, whether it's cucumber or
something else.

Post by QuBiT
So maybe just change the Wiki and add a Note that such issues can be
found in the History.txt.

Added: http://wiki.github.com/aslakhellesoy/cucumber/upgrading

Post by QuBiT
Adding a post-install message could be useful (but only if someone
reads them ^^),

People who upgrade without reading History.txt OR a post install
message (which I will add in the next release) are sloppy. There is nothing
I can do to help in that case. ;-)
Aslak
but I think a better Wiki page (thought that this is

Post by QuBiT
the main documentation source for cucumber) would be enough.
Cheers QuBiT

This changed in 0.3.102 and 0.3.103
The API to turn on and off transactions has changed.
Run script/generate cucumber
This will generate a new features/support/env.rb file that uses the

new API.

Post by aslak hellesoy
(You'll see how the API is different when you do that).
Every now and then there are slight API changes that require a

regeneration

users to run

Post by aslak hellesoy
script/generate cucumber?
Aslak

Post by QuBiT
I have checked my env.rb in features/support and I have this lines

you

Post by QuBiT
don't want Cucumber Unicode support
Cucumber::Rails.use_transactional_fixtures
Downgrading (uninstalling 0.3.104 and reinstalling 0.3.101) works

and

Post by QuBiT
running "rake features" does not throw an error.
So PLEASE help me to get rid of this error.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Cukes" group.
To post to this group, send email to cukes-/***@public.gmane.org
To unsubscribe from this group, send email to cukes+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/cukes?hl=en
-~----------~----~----~----~------~----~------~--~---

Stephen Bannasch

2009-10-15 20:21:01 UTC

Post by Assaf Arkin
- lib/cucumber/formatter/html.rb requires ruby-debug
This was a classic mistake. Matt had forgotten to take it out while he refactored the hell out of formatters to enable a more
pluggable lifecycle mechanism. I overlooked it when I merged it in and didn't notice it because I happened to have ruby-debug
installed. This kind of bug is unfortunate, but almost impossible to pick up automatically. The only thing that can catch it
iseyeballing. Fortunately this kind of oversight is rare.

I often create a new JRuby VM just to test this this kind of thing.

It's easy to install multiple JRuby's rooted in separate directories where they have no connection to system gems.

So if you define the minimum set of gems necessary -- perhaps just rubygems, it's not hard to then automate the installation
ofcucumber and friends and to test for these kind of errors.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Cukes" group.
To post to this group, send email to cukes-/***@public.gmane.org
To unsubscribe from this group, send email to cukes+unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/cukes?hl=en
-~----------~----~----~----~------~----~------~--~---

Jim Meyer

2009-09-28 19:39:28 UTC

On 9/28/09 11:23 AM, Assaf Arkin wrote:
[...]

Post by Assaf Arkin
I don't see much correlation between reading history.txt and avoiding my
setup from breaking. Merely allowing gem update to download a new
version of Cucumber is living dangerously. Any plans on dampening the
rate of regressions?

One trick I've employed to understand changes and dependencies in
hyperactive open-source projects is to run the previous version's tests
against the current code; this tells you where things you may care about
have changed.

I have to say that I don't agree with Aslak that you must read release
notes to upgrade, but I very much do believe you should be freezing the
gems in your app or otherwise locking dependencies to a specific version
for any production app. For development, I tend to lock them for any
project whose API is in flux (like Cucumber) or otherwise moving faster
than I have time to test and adjust to.

FWIW.

--j

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Cukes" group.
To post to this group, send email to cukes-/***@public.gmane.org
To unsubscribe from this group, send email to cukes+unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/cukes?hl=en
-~----------~----~----~----~------~----~------~--~---

Stephen Eley

2009-09-29 03:35:50 UTC

On Mon, Sep 28, 2009 at 5:30 AM, aslak hellesoy

Post by aslak hellesoy
Should I add a post-install message for the gem reminding Rails users to run
script/generate cucumber?

I think that's a great idea. The post-install message could also
include those bullet points from the History.txt file that represent
changes to end user functionality. That's really what it's for -- and
it has higher and more immediate visibility than changelogs. Even if
you think developers who don't RTFM on every update are idiots who
deserve it when things break, it's still a courtesy for developer
efficiency; running "sudo gem update" once a week can sometimes result
in six to ten gem updates. Seeing the changes during the process is
faster than having to open up every gem's directory and look for six
to ten text files. (I wish more gems would take this cue from GUI
application developers.)

Also please consider the discussion from a few days ago about
separating "generated" code from "local" code. Env.rb and
webrat_steps.rb are rewritten often enough that end users should
probably be advised away from making extensive changes to them,
putting their custom setup into local files instead that don't get
updated. That saves time during the inevitable "diff and merge" step.
This is really more a matter of documentation and convention than
retooling, but there are ways you could provide guidance within the
generated code. (Paths.rb, on the other hand, would need retooling to
make this work well.)
--
Have Fun,
Steve Eley (sfeley-***@public.gmane.org)
ESCAPE POD - The Science Fiction Podcast Magazine
http://www.escapepod.org

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Cukes" group.
To post to this group, send email to cukes-/***@public.gmane.org
To unsubscribe from this group, send email to cukes+unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/cukes?hl=en
-~----------~----~----~----~------~----~------~--~---

Mike Sassak

2009-09-29 05:02:46 UTC

Post by Stephen Eley
On Mon, Sep 28, 2009 at 5:30 AM, aslak hellesoy

Post by aslak hellesoy
Should I add a post-install message for the gem reminding Rails users to

run

Post by aslak hellesoy
script/generate cucumber?

I think that's a great idea. The post-install message could also
include those bullet points from the History.txt file that represent
changes to end user functionality. That's really what it's for -- and
it has higher and more immediate visibility than changelogs. Even if
you think developers who don't RTFM on every update are idiots who
deserve it when things break, it's still a courtesy for developer
efficiency; running "sudo gem update" once a week can sometimes result
in six to ten gem updates. Seeing the changes during the process is
faster than having to open up every gem's directory and look for six
to ten text files. (I wish more gems would take this cue from GUI
application developers.)
Also please consider the discussion from a few days ago about
separating "generated" code from "local" code. Env.rb and
webrat_steps.rb are rewritten often enough that end users should
probably be advised away from making extensive changes to them,
putting their custom setup into local files instead that don't get
updated. That saves time during the inevitable "diff and merge" step.
This is really more a matter of documentation and convention than
retooling, but there are ways you could provide guidance within the
generated code. (Paths.rb, on the other hand, would need retooling to
make this work well.)

I second Jim's suggestion to freeze dependencies. I think running "sudo gem
update" once a week is a recipe for disaster unless you've taken the time to
freeze. I can understand being annoyed if Cucumber has bugs that don't allow
two versions to be installed and used side by side--that's a pretty common
situation, but if you upgrade a dependency for whatever reason and are
surprised when things break, you should reconsider your upgrade strategy.
Reading the change log is important, but it's only the beginning. Every new
version is a new version and should be treated as such.

Compare the situation with Cucumber to the development of a major Linux
distro like Debian. They have stable, testing and unstable channels.
Cucumber doesn't have enough active members to support anything like this,
so it's up to the developer to find a known stable version and make sure
you're always developing with that version. If you run into bugs in the
library you're using and need to upgrade, when you upgrade you yourself need
to simulate something like the path a library would take in a project like
Debian: from unstable to testing to stable. That takes time, but there's no
replacement for it.

Having said all that, it certainly *feels* like the 0.3.x series has been
going on forever--though I readily admit I have no numbers to back this
up--but I wonder, nevertheless, if that's not contributing to people
expecting smoother upgrades. I think going back to less frequent releases on
Rubyforge would help. Perhaps even adopting an even/stable odd/unstable
policy as well. The Linux kernel (used) to do this, and I think it works
pretty well without causing too many headaches.

Mike

Post by Stephen Eley
--
Have Fun,
ESCAPE POD - The Science Fiction Podcast Magazine
http://www.escapepod.org

Stephen Eley

2009-09-29 05:47:03 UTC

Post by Mike Sassak
I second Jim's suggestion to freeze dependencies. I think running "sudo gem
update" once a week is a recipe for disaster unless you've taken the time to
freeze. I can understand being annoyed if Cucumber has bugs that don't allow
two versions to be installed and used side by side--that's a pretty common
situation, but if you upgrade a dependency for whatever reason and are
surprised when things break, you should reconsider your upgrade strategy.

This sounds sort of preachy. Everyone has different styles, different
risk tolerances, different project needs and different motivations.
There is no One Right Way to do this. Heck, for some of us, "Let's
try it and see what breaks" creates a sense of adventure that's part
of the fun of programming. Maybe for you that doesn't seem
reasonable. That's fine. I'm not going to tell you what your style
should be.

I've never said here that Cucumber should update less frequently.
I've never said it shouldn't have bugs or change its behavior. It's
pre-1.0, and I expect this sort of flux. I am _not_ "surprised when
things break." I'm comfortable with it. My suggestions to Aslak were
not "Stop breaking stuff." I'd honestly rather see stuff breaking
occasionally than working-but-never-improving.

Rather, I suggest that a gem which updates frequently and includes
generators can make certain documentation and stylistic choices to
make life easier for developers who _choose_ to keep up with those
frequent updates. I don't think this is an unreasonable suggestion.
And I don't think facilitating easy upgrades or making information
more accessible hurts anybody's cause. When you eventually do find a
reason to upgrade your frozen gems, these are suggestions that will
help you too.

The fact that Cucumber development is so rapid creates options. I
usually choose to exercise the option to stay current with it. It's
an informed choice. I don't expect it to be risk-free. I don't
expect it to be zero-effort or to take no time. But I also don't
expect it to be harder than it _has_ to be. And I don't expect
derision for exercising a different choice than you did.
--
Have Fun,
Steve Eley (sfeley-***@public.gmane.org)
ESCAPE POD - The Science Fiction Podcast Magazine
http://www.escapepod.org

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Cukes" group.
To post to this group, send email to cukes-/***@public.gmane.org
To unsubscribe from this group, send email to cukes+unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/cukes?hl=en
-~----------~----~----~----~------~----~------~--~---

Mike Sassak

2009-09-29 06:07:09 UTC

Post by Mike Sassak
I second Jim's suggestion to freeze dependencies. I think running "sudo

gem

Post by Mike Sassak
update" once a week is a recipe for disaster unless you've taken the time

Post by Mike Sassak
freeze. I can understand being annoyed if Cucumber has bugs that don't

allow

Post by Mike Sassak
two versions to be installed and used side by side--that's a pretty

common

Post by Mike Sassak
situation, but if you upgrade a dependency for whatever reason and are
surprised when things break, you should reconsider your upgrade strategy.

This sounds sort of preachy. Everyone has different styles, different
risk tolerances, different project needs and different motivations.
There is no One Right Way to do this. Heck, for some of us, "Let's
try it and see what breaks" creates a sense of adventure that's part
of the fun of programming. Maybe for you that doesn't seem
reasonable. That's fine. I'm not going to tell you what your style
should be.
I've never said here that Cucumber should update less frequently.
I've never said it shouldn't have bugs or change its behavior. It's
pre-1.0, and I expect this sort of flux. I am _not_ "surprised when
things break." I'm comfortable with it. My suggestions to Aslak were
not "Stop breaking stuff." I'd honestly rather see stuff breaking
occasionally than working-but-never-improving.
Rather, I suggest that a gem which updates frequently and includes
generators can make certain documentation and stylistic choices to
make life easier for developers who _choose_ to keep up with those
frequent updates. I don't think this is an unreasonable suggestion.
And I don't think facilitating easy upgrades or making information
more accessible hurts anybody's cause. When you eventually do find a
reason to upgrade your frozen gems, these are suggestions that will
help you too.
The fact that Cucumber development is so rapid creates options. I
usually choose to exercise the option to stay current with it. It's
an informed choice. I don't expect it to be risk-free. I don't
expect it to be zero-effort or to take no time. But I also don't
expect it to be harder than it _has_ to be. And I don't expect
derision for exercising a different choice than you did.

No derision or preaching intended. I was just replying to the last message
in the thread, and doing my best to hit on what I thought were some
repeating themes without writing a novel. To be clear, when I was talking
about gem update'ing everything, I was thinking of the effect of that on a
long-running, "professional" (for lack of a better term) project, with a
very large number of unfrozen dependencies. My apologies. :-)

Post by Mike Sassak
--
Have Fun,
ESCAPE POD - The Science Fiction Podcast Magazine
http://www.escapepod.org

Stephen Eley

2009-09-29 13:36:20 UTC

Post by Mike Sassak
No derision or preaching intended. I was just replying to the last message
in the thread, and doing my best to hit on what I thought were some
repeating themes without writing a novel. To be clear, when I was talking
about gem update'ing everything, I was thinking of the effect of that on a
long-running, "professional" (for lack of a better term) project, with a
very large number of unfrozen dependencies. My apologies. :-)

Thanks, and no worries. On a second read and a good night's sleep, I
believe I was overly touchy.

By way of defusing any tension here (and further reducing any
possibility that this thread will get back on topic) >8-> here's my
old friend Rudyard Kipling:

* * * *

IN THE Neolithic Age savage warfare did I wage
For food and fame and woolly horses' pelt.
I was singer to my clan in that dim, red Dawn of Man,
And I sang of all we fought and feared and felt.

Yea, I sang as now I sing, when the Prehistoric spring
Made the piled Biscayan ice-pack split and shove;
And the troll and gnome and dwerg, and the Gods of Cliff and Berg
Were about me and beneath me and above.

But a rival, of Solutre, told the tribe my style was outre-
'Neath a tomahawk, of diorite, he fell
And I left my views on Art, barbed and tanged, below the heart
Of a mammothistic etcher at Grenelle.

Then I stripped them, scalp from skull, and my hunting-dogs fed full,
And their teeth I threaded neatly on a thong;
And I wiped my mouth and said, "It is well that they are dead,
For I know my work is right and theirs was wrong."

But my Totem saw the shame; from his ridgepole-shrine he came,
And he told me in a vision of the night: -
"There are nine and sixty ways of constructing tribal lays,
"And every single one of them is right!"

* * * *

Then the silence closed upon me till They put new clothing on me
Of whiter, weaker flesh and bone more frail;
. And I stepped beneath Time's finger, once again a tribal singer,
And a minor poet certified by Traill!

Still they skirmish to and fro, men my messmates on the snow
When we headed off the aurochs turn for turn;
When the rich Allobrogenses never kept amanuenses,
And our only plots were piled in lakes at Berne.

Still a cultured Christian age sees us scuffle, squeak, and rage,
Still we pinch and slap and jabber, scratch and dirk;
Still we let our business slide-as we dropped the half-dressed hide-
To show a fellow-savage how to work.

Still the world is wondrous large,-seven seas from marge to marge-
And it holds a vast of various kinds of man;
And the wildest dreams of Kew are the facts of Khatmandhu
And the crimes of Clapham chaste in Martaban.

Here's my wisdom for your use, as I learned it when the moose
And the reindeer roamed where Paris roars to-night:-
"There are nine and sixty ways of constructing tribal lays,
"And-every-single-one-of-them-is-right!"
--
Have Fun,
Steve Eley (sfeley-***@public.gmane.org)
ESCAPE POD - The Science Fiction Podcast Magazine
http://www.escapepod.org

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Cukes" group.
To post to this group, send email to cukes-/***@public.gmane.org
To unsubscribe from this group, send email to cukes+unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/cukes?hl=en
-~----------~----~----~----~------~----~------~--~---

aslak hellesoy

2009-09-29 14:25:32 UTC

Post by QuBiT

Post by Mike Sassak
No derision or preaching intended. I was just replying to the last

message

Post by Mike Sassak
in the thread, and doing my best to hit on what I thought were some
repeating themes without writing a novel. To be clear, when I was talking
about gem update'ing everything, I was thinking of the effect of that on

Post by Mike Sassak
long-running, "professional" (for lack of a better term) project, with a
very large number of unfrozen dependencies. My apologies. :-)

Thanks, and no worries. On a second read and a good night's sleep, I
believe I was overly touchy.
By way of defusing any tension here (and further reducing any
possibility that this thread will get back on topic) >8-> here's my
* * * *
IN THE Neolithic Age savage warfare did I wage
For food and fame and woolly horses' pelt.
I was singer to my clan in that dim, red Dawn of Man,
And I sang of all we fought and feared and felt.
Yea, I sang as now I sing, when the Prehistoric spring
Made the piled Biscayan ice-pack split and shove;
And the troll and gnome and dwerg, and the Gods of Cliff and Berg
Were about me and beneath me and above.
But a rival, of Solutre, told the tribe my style was outre-
'Neath a tomahawk, of diorite, he fell
And I left my views on Art, barbed and tanged, below the heart
Of a mammothistic etcher at Grenelle.
Then I stripped them, scalp from skull, and my hunting-dogs fed full,
And their teeth I threaded neatly on a thong;
And I wiped my mouth and said, "It is well that they are dead,
For I know my work is right and theirs was wrong."
But my Totem saw the shame; from his ridgepole-shrine he came,
And he told me in a vision of the night: -
"There are nine and sixty ways of constructing tribal lays,
"And every single one of them is right!"
* * * *
Then the silence closed upon me till They put new clothing on me
Of whiter, weaker flesh and bone more frail;
. And I stepped beneath Time's finger, once again a tribal singer,
And a minor poet certified by Traill!
Still they skirmish to and fro, men my messmates on the snow
When we headed off the aurochs turn for turn;
When the rich Allobrogenses never kept amanuenses,
And our only plots were piled in lakes at Berne.
Still a cultured Christian age sees us scuffle, squeak, and rage,
Still we pinch and slap and jabber, scratch and dirk;
Still we let our business slide-as we dropped the half-dressed hide-
To show a fellow-savage how to work.
Still the world is wondrous large,-seven seas from marge to marge-
And it holds a vast of various kinds of man;
And the wildest dreams of Kew are the facts of Khatmandhu
And the crimes of Clapham chaste in Martaban.
Here's my wisdom for your use, as I learned it when the moose
And the reindeer roamed where Paris roars to-night:-
"There are nine and sixty ways of constructing tribal lays,
"And-every-single-one-of-them-is-right!"

Good old Rudyard. I used to love the The Cat that Walked By Himself as a
boy.
Hijacking this thread to poetry and verse is a great idea. Here is one of my
favourite folk songs:

(Norwegian)
Eg rodde meg ut på seiegrunnen
det var om morgonen tidleg.
Då kom han Olav frå Kåremunnen,
og lagde båten for ile.
Då dreiv eg til han med fiskestongi,
sån datt i uvitet bak i rongi.
Eg vart so glad, eg tok til og kvad,
eg rådde grunnen åleine.
Sudeli sudeli sudeli dei hoi!

(English)
I rowed out to the fishing grounds,
It was early in the morning.
Then along came Olav from Karemunnen,
And put his boat to rest there, too.
Then I hit him with my fishing pole
So that he fell unconscious in the back of the boat.
I was so happy, I started to sing,
I had the fishing grounds all to myself.
Sudeli, sudeli, sudeli hei ho!

Aslak

Post by QuBiT
--
Have Fun,
ESCAPE POD - The Science Fiction Podcast Magazine
http://www.escapepod.org

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Cukes" group.
To post to this group, send email to cukes-/***@public.gmane.org
To unsubscribe from this group, send email to cukes+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/cukes?hl=en
-~----------~----~----~----~------~----~------~--~---

Mike Sassak

2009-09-29 16:45:51 UTC

On Tue, Sep 29, 2009 at 10:25 AM, aslak hellesoy

Post by QuBiT

Post by Mike Sassak
No derision or preaching intended. I was just replying to the last

message

Post by Mike Sassak
in the thread, and doing my best to hit on what I thought were some
repeating themes without writing a novel. To be clear, when I was

talking

Post by Mike Sassak
about gem update'ing everything, I was thinking of the effect of that on

Post by Mike Sassak
long-running, "professional" (for lack of a better term) project, with a
very large number of unfrozen dependencies. My apologies. :-)

Thanks, and no worries. On a second read and a good night's sleep, I
believe I was overly touchy.
By way of defusing any tension here (and further reducing any
possibility that this thread will get back on topic) >8-> here's my
* * * *
IN THE Neolithic Age savage warfare did I wage
For food and fame and woolly horses' pelt.
I was singer to my clan in that dim, red Dawn of Man,
And I sang of all we fought and feared and felt.
Yea, I sang as now I sing, when the Prehistoric spring
Made the piled Biscayan ice-pack split and shove;
And the troll and gnome and dwerg, and the Gods of Cliff and Berg
Were about me and beneath me and above.
But a rival, of Solutre, told the tribe my style was outre-
'Neath a tomahawk, of diorite, he fell
And I left my views on Art, barbed and tanged, below the heart
Of a mammothistic etcher at Grenelle.
Then I stripped them, scalp from skull, and my hunting-dogs fed full,
And their teeth I threaded neatly on a thong;
And I wiped my mouth and said, "It is well that they are dead,
For I know my work is right and theirs was wrong."
But my Totem saw the shame; from his ridgepole-shrine he came,
And he told me in a vision of the night: -
"There are nine and sixty ways of constructing tribal lays,
"And every single one of them is right!"
* * * *
Then the silence closed upon me till They put new clothing on me
Of whiter, weaker flesh and bone more frail;
. And I stepped beneath Time's finger, once again a tribal singer,
And a minor poet certified by Traill!
Still they skirmish to and fro, men my messmates on the snow
When we headed off the aurochs turn for turn;
When the rich Allobrogenses never kept amanuenses,
And our only plots were piled in lakes at Berne.
Still a cultured Christian age sees us scuffle, squeak, and rage,
Still we pinch and slap and jabber, scratch and dirk;
Still we let our business slide-as we dropped the half-dressed hide-
To show a fellow-savage how to work.
Still the world is wondrous large,-seven seas from marge to marge-
And it holds a vast of various kinds of man;
And the wildest dreams of Kew are the facts of Khatmandhu
And the crimes of Clapham chaste in Martaban.
Here's my wisdom for your use, as I learned it when the moose
And the reindeer roamed where Paris roars to-night:-
"There are nine and sixty ways of constructing tribal lays,
"And-every-single-one-of-them-is-right!"

Good old Rudyard. I used to love the The Cat that Walked By Himself as a
boy.
Hijacking this thread to poetry and verse is a great idea. Here is one of
(Norwegian)
Eg rodde meg ut på seiegrunnen
det var om morgonen tidleg.
Då kom han Olav frå Kåremunnen,
og lagde båten for ile.
Då dreiv eg til han med fiskestongi,
sån datt i uvitet bak i rongi.
Eg vart so glad, eg tok til og kvad,
eg rådde grunnen åleine.
Sudeli sudeli sudeli dei hoi!
(English)
I rowed out to the fishing grounds,
It was early in the morning.
Then along came Olav from Karemunnen,
And put his boat to rest there, too.
Then I hit him with my fishing pole
So that he fell unconscious in the back of the boat.
I was so happy, I started to sing,
I had the fishing grounds all to myself.
Sudeli, sudeli, sudeli hei ho!

Remind me never to go fishing with a Norwegian. ;-)

I never expected I'd be able to fit this into a thread here, but there's a
stanza of Goethe's I think of sometimes when dealing with requests for new
features on a very short timeline:

"Ein Huendchen wird gesucht,
Das weder murrt, noch beisst,
Zerbrochene Glaeser frisst,
Und diamanten scheisst."

"Wanted: a puppy
That neither growls nor bites,
Eats broken glass,
And shits diamonds."

Mike

Aslak

Post by QuBiT
--
Have Fun,
ESCAPE POD - The Science Fiction Podcast Magazine
http://www.escapepod.org

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Cukes" group.
To post to this group, send email to cukes-/***@public.gmane.org
To unsubscribe from this group, send email to cukes+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/cukes?hl=en
-~----------~----~----~----~------~----~------~--~---

Assaf Arkin

2009-09-29 06:14:28 UTC

Post by Stephen Eley
On Mon, Sep 28, 2009 at 5:30 AM, aslak hellesoy

Post by aslak hellesoy
Should I add a post-install message for the gem reminding Rails users to

run

Post by aslak hellesoy
script/generate cucumber?

I think that's a great idea. The post-install message could also
include those bullet points from the History.txt file that represent
changes to end user functionality. That's really what it's for -- and
it has higher and more immediate visibility than changelogs. Even if
you think developers who don't RTFM on every update are idiots who
deserve it when things break, it's still a courtesy for developer
efficiency; running "sudo gem update" once a week can sometimes result
in six to ten gem updates. Seeing the changes during the process is
faster than having to open up every gem's directory and look for six
to ten text files. (I wish more gems would take this cue from GUI
application developers.)
Also please consider the discussion from a few days ago about
separating "generated" code from "local" code. Env.rb and
webrat_steps.rb are rewritten often enough that end users should
probably be advised away from making extensive changes to them,
putting their custom setup into local files instead that don't get
updated. That saves time during the inevitable "diff and merge" step.
This is really more a matter of documentation and convention than
retooling, but there are ways you could provide guidance within the
generated code. (Paths.rb, on the other hand, would need retooling to
make this work well.)

$ gem list | wc -l
84

I think I average about 10 gem updates a week. On three different setups.
Then there's also Git vendor, MacPort, apt-get (three different setups),
regular apps, system updates, and occasional Rails edge.

That's a lot of updates going on a regular basis, yet only a handful of
sources that cause my any pain. So you have to wonder, is my upgrade
strategy broken, or just these specific libraries?

You also have to decide, when users tell you the tool is great but have
gripes with certain aspects of it, do you fix these issues, or do you try to
fix the users?

Post by Mike Sassak
Reading the change log is important, but it's only the beginning. Every
new version is a new version and should be treated as such.

Courtesy link to the RubyGems Manual section on versioning policies:

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

Assaf

Post by Mike Sassak
Compare the situation with Cucumber to the development of a major Linux
distro like Debian. They have stable, testing and unstable channels.
Cucumber doesn't have enough active members to support anything like this,
so it's up to the developer to find a known stable version and make sure
you're always developing with that version. If you run into bugs in the
library you're using and need to upgrade, when you upgrade you yourself need
to simulate something like the path a library would take in a project like
Debian: from unstable to testing to stable. That takes time, but there's no
replacement for it.
Having said all that, it certainly *feels* like the 0.3.x series has been
going on forever--though I readily admit I have no numbers to back this
up--but I wonder, nevertheless, if that's not contributing to people
expecting smoother upgrades. I think going back to less frequent releases on
Rubyforge would help. Perhaps even adopting an even/stable odd/unstable
policy as well. The Linux kernel (used) to do this, and I think it works
pretty well without causing too many headaches.
Mike

Post by Stephen Eley
--
Have Fun,
ESCAPE POD - The Science Fiction Podcast Magazine
http://www.escapepod.org

Mike Sassak

2009-09-29 06:40:05 UTC

Post by Stephen Eley
On Mon, Sep 28, 2009 at 5:30 AM, aslak hellesoy

Post by aslak hellesoy
Should I add a post-install message for the gem reminding Rails users

to run

Post by aslak hellesoy
script/generate cucumber?

I think that's a great idea. The post-install message could also
include those bullet points from the History.txt file that represent
changes to end user functionality. That's really what it's for -- and
it has higher and more immediate visibility than changelogs. Even if
you think developers who don't RTFM on every update are idiots who
deserve it when things break, it's still a courtesy for developer
efficiency; running "sudo gem update" once a week can sometimes result
in six to ten gem updates. Seeing the changes during the process is
faster than having to open up every gem's directory and look for six
to ten text files. (I wish more gems would take this cue from GUI
application developers.)
Also please consider the discussion from a few days ago about
separating "generated" code from "local" code. Env.rb and
webrat_steps.rb are rewritten often enough that end users should
probably be advised away from making extensive changes to them,
putting their custom setup into local files instead that don't get
updated. That saves time during the inevitable "diff and merge" step.
This is really more a matter of documentation and convention than
retooling, but there are ways you could provide guidance within the
generated code. (Paths.rb, on the other hand, would need retooling to
make this work well.)

$ gem list | wc -l
84
I think I average about 10 gem updates a week. On three different setups.
Then there's also Git vendor, MacPort, apt-get (three different setups),
regular apps, system updates, and occasional Rails edge.
That's a lot of updates going on a regular basis, yet only a handful of
sources that cause my any pain. So you have to wonder, is my upgrade
strategy broken, or just these specific libraries?
You also have to decide, when users tell you the tool is great but have
gripes with certain aspects of it, do you fix these issues, or do you try to
fix the users?

Post by Mike Sassak
Reading the change log is important, but it's only the beginning. Every
new version is a new version and should be treated as such.

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

Hi Assaf,

I update lots of things regularly, too. It's part and parcel of working with
computers. But if I know a specific library I am using is undergoing rapid
changes, I am more careful about changing that one, perhaps setting aside
extra time for those upgrades. I wouldn't, for example, run a cron job with
apt-get update/upgrade on a box running Debian unstable if I needed to be
sure that machine would be available. For open source projects, if the rate
of change is too great for me but I need a specific bug fix, I'll also fork
the repo, branch, cherry-pick what I need and then freeze a gem built from
that branch. Perhaps something like that could help you while Cucumber
stabilizes?

Mike

Post by Assaf Arkin
Assaf

Post by Stephen Eley
--
Have Fun,
ESCAPE POD - The Science Fiction Podcast Magazine
http://www.escapepod.org

Assaf Arkin

2009-09-29 07:03:48 UTC

Post by Stephen Eley
On Mon, Sep 28, 2009 at 5:30 AM, aslak hellesoy

Post by aslak hellesoy
Should I add a post-install message for the gem reminding Rails users

to run

Post by aslak hellesoy
script/generate cucumber?

I think that's a great idea. The post-install message could also
include those bullet points from the History.txt file that represent
changes to end user functionality. That's really what it's for -- and
it has higher and more immediate visibility than changelogs. Even if
you think developers who don't RTFM on every update are idiots who
deserve it when things break, it's still a courtesy for developer
efficiency; running "sudo gem update" once a week can sometimes result
in six to ten gem updates. Seeing the changes during the process is
faster than having to open up every gem's directory and look for six
to ten text files. (I wish more gems would take this cue from GUI
application developers.)
Also please consider the discussion from a few days ago about
separating "generated" code from "local" code. Env.rb and
webrat_steps.rb are rewritten often enough that end users should
probably be advised away from making extensive changes to them,
putting their custom setup into local files instead that don't get
updated. That saves time during the inevitable "diff and merge" step.
This is really more a matter of documentation and convention than
retooling, but there are ways you could provide guidance within the
generated code. (Paths.rb, on the other hand, would need retooling to
make this work well.)

$ gem list | wc -l
84
I think I average about 10 gem updates a week. On three different setups.
Then there's also Git vendor, MacPort, apt-get (three different setups),
regular apps, system updates, and occasional Rails edge.
That's a lot of updates going on a regular basis, yet only a handful of
sources that cause my any pain. So you have to wonder, is my upgrade
strategy broken, or just these specific libraries?
You also have to decide, when users tell you the tool is great but have
gripes with certain aspects of it, do you fix these issues, or do you try to
fix the users?

Post by Mike Sassak
Reading the change log is important, but it's only the beginning. Every
new version is a new version and should be treated as such.

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

Hi Assaf,
I update lots of things regularly, too. It's part and parcel of working
with computers. But if I know a specific library I am using is undergoing
rapid changes, I am more careful about changing that one, perhaps setting
aside extra time for those upgrades. I wouldn't, for example, run a cron job
with apt-get update/upgrade on a box running Debian unstable if I needed to
be sure that machine would be available. For open source projects, if the
rate of change is too great for me but I need a specific bug fix, I'll also
fork the repo, branch, cherry-pick what I need and then freeze a gem built
from that branch. Perhaps something like that could help you while Cucumber
stabilizes?

I'm trying to decide if Cucumber has reached the point where I can take it
seriously, depend on it and recommend it to others, or I should just let it
go and find something else to use.

There's no need to defend an ad hoc release process, or teach me how to use
Git. A simple "not ready for production yet" would suffice.

Assaf

Post by Mike Sassak
Mike

Post by Assaf Arkin
Assaf

Post by Stephen Eley
--
Have Fun,
ESCAPE POD - The Science Fiction Podcast Magazine
http://www.escapepod.org

aslak hellesoy

2009-09-29 13:59:11 UTC

Post by Stephen Eley
On Mon, Sep 28, 2009 at 5:30 AM, aslak hellesoy

Post by aslak hellesoy
Should I add a post-install message for the gem reminding Rails users

to run

Post by aslak hellesoy
script/generate cucumber?

I think that's a great idea. The post-install message could also
include those bullet points from the History.txt file that represent
changes to end user functionality. That's really what it's for -- and
it has higher and more immediate visibility than changelogs. Even if
you think developers who don't RTFM on every update are idiots who
deserve it when things break, it's still a courtesy for developer
efficiency; running "sudo gem update" once a week can sometimes result
in six to ten gem updates. Seeing the changes during the process is
faster than having to open up every gem's directory and look for six
to ten text files. (I wish more gems would take this cue from GUI
application developers.)
Also please consider the discussion from a few days ago about
separating "generated" code from "local" code. Env.rb and
webrat_steps.rb are rewritten often enough that end users should
probably be advised away from making extensive changes to them,
putting their custom setup into local files instead that don't get
updated. That saves time during the inevitable "diff and merge" step.
This is really more a matter of documentation and convention than
retooling, but there are ways you could provide guidance within the
generated code. (Paths.rb, on the other hand, would need retooling to
make this work well.)

$ gem list | wc -l
84
I think I average about 10 gem updates a week. On three different setups.
Then there's also Git vendor, MacPort, apt-get (three different setups),
regular apps, system updates, and occasional Rails edge.
That's a lot of updates going on a regular basis, yet only a handful of
sources that cause my any pain. So you have to wonder, is my upgrade
strategy broken, or just these specific libraries?
You also have to decide, when users tell you the tool is great but have
gripes with certain aspects of it, do you fix these issues, or do you try to
fix the users?

Post by Mike Sassak
Reading the change log is important, but it's only the beginning. Every
new version is a new version and should be treated as such.

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

Hi Assaf,
I update lots of things regularly, too. It's part and parcel of working
with computers. But if I know a specific library I am using is undergoing
rapid changes, I am more careful about changing that one, perhaps setting
aside extra time for those upgrades. I wouldn't, for example, run a cron job
with apt-get update/upgrade on a box running Debian unstable if I needed to
be sure that machine would be available. For open source projects, if the
rate of change is too great for me but I need a specific bug fix, I'll also
fork the repo, branch, cherry-pick what I need and then freeze a gem built
from that branch. Perhaps something like that could help you while Cucumber
stabilizes?

I'm trying to decide if Cucumber has reached the point where I can take it
seriously, depend on it and recommend it to others, or I should just let it
go and find something else to use.

I'm not sure what criteria you have for taking something seriously, but like
I mentioned in my previous post in this thread - Cucumber hasn't had a major
release yet. There is a big ecosystem around it dragging it in all sorts of
directions, and sometimes the damn thing gets stretched a little too far
before it's patched up again. Big deal, just downgrade your gem to what
worked for you previously and register an issue, send a short email or come
to IRC.

Post by Assaf Arkin
There's no need to defend an ad hoc release process, or teach me how to use
Git. A simple "not ready for production yet" would suffice.

Saying whether or not it's ready for production is impossible without taking
context into consideration. Plenty of people use Cucumber on real systems
that are in production. It boils down cost/benefit. If the total benefit you
get from increased quality with Cucumber scenarios outweigh the cost of
occasional upgrade-related problems? And is this cost/benefit more favorable
than an alternative to Cucumber?

If so, use it. If not, don't. Only you can decide what makes sense for you.

And things will get better with time.

Post by Assaf Arkin
Assaf

Post by Mike Sassak
Mike

Post by Assaf Arkin
Assaf

Post by Mike Sassak
Compare the situation with Cucumber to the development of a major Linux
distro like Debian. They have stable, testing and unstable channels.
Cucumber doesn't have enough active members to support anything like this,
so it's up to the developer to find a known stable version and make sure
you're always developing with that version. If you run into bugs in the
library you're using and need to upgrade, when you upgrade you yourself need
to simulate something like the path a library would take in a project like
Debian: from unstable to testing to stable. That takes time, but there's no
replacement for it.
Having said all that, it certainly *feels* like the 0.3.x series has
been going on forever--though I readily admit I have no numbers to back this
up--but I wonder, nevertheless, if that's not contributing to people
expecting smoother upgrades. I think going back to less frequent releases on
Rubyforge would help. Perhaps even adopting an even/stable odd/unstable
policy as well. The Linux kernel (used) to do this, and I think it works
pretty well without causing too many headaches.
Mike

Post by Stephen Eley
--
Have Fun,
ESCAPE POD - The Science Fiction Podcast Magazine
http://www.escapepod.org

Assaf Arkin

2009-09-29 17:05:11 UTC

Post by Stephen Eley
On Mon, Sep 28, 2009 at 5:30 AM, aslak hellesoy

Post by aslak hellesoy
Should I add a post-install message for the gem reminding Rails

users to run

Post by aslak hellesoy
script/generate cucumber?

I think that's a great idea. The post-install message could also
include those bullet points from the History.txt file that represent
changes to end user functionality. That's really what it's for -- and
it has higher and more immediate visibility than changelogs. Even if
you think developers who don't RTFM on every update are idiots who
deserve it when things break, it's still a courtesy for developer
efficiency; running "sudo gem update" once a week can sometimes result
in six to ten gem updates. Seeing the changes during the process is
faster than having to open up every gem's directory and look for six
to ten text files. (I wish more gems would take this cue from GUI
application developers.)
Also please consider the discussion from a few days ago about
separating "generated" code from "local" code. Env.rb and
webrat_steps.rb are rewritten often enough that end users should
probably be advised away from making extensive changes to them,
putting their custom setup into local files instead that don't get
updated. That saves time during the inevitable "diff and merge" step.
This is really more a matter of documentation and convention than
retooling, but there are ways you could provide guidance within the
generated code. (Paths.rb, on the other hand, would need retooling to
make this work well.)

$ gem list | wc -l
84
I think I average about 10 gem updates a week. On three different
setups. Then there's also Git vendor, MacPort, apt-get (three different
setups), regular apps, system updates, and occasional Rails edge.
That's a lot of updates going on a regular basis, yet only a handful of
sources that cause my any pain. So you have to wonder, is my upgrade
strategy broken, or just these specific libraries?
You also have to decide, when users tell you the tool is great but have
gripes with certain aspects of it, do you fix these issues, or do you try to
fix the users?

Post by Mike Sassak
Reading the change log is important, but it's only the beginning.
Every new version is a new version and should be treated as such.

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

Hi Assaf,
I update lots of things regularly, too. It's part and parcel of working
with computers. But if I know a specific library I am using is undergoing
rapid changes, I am more careful about changing that one, perhaps setting
aside extra time for those upgrades. I wouldn't, for example, run a cron job
with apt-get update/upgrade on a box running Debian unstable if I needed to
be sure that machine would be available. For open source projects, if the
rate of change is too great for me but I need a specific bug fix, I'll also
fork the repo, branch, cherry-pick what I need and then freeze a gem built
from that branch. Perhaps something like that could help you while Cucumber
stabilizes?

I'm trying to decide if Cucumber has reached the point where I can take it
seriously, depend on it and recommend it to others, or I should just let it
go and find something else to use.

I'm not sure what criteria you have for taking something seriously, but
like I mentioned in my previous post in this thread - Cucumber hasn't had a
major release yet. There is a big ecosystem around it dragging it in all
sorts of directions, and sometimes the damn thing gets stretched a little
too far before it's patched up again. Big deal, just downgrade your gem to
what worked for you previously and register an issue, send a short email or
come to IRC.

Let me again iterate what I said. Big ecosystem, major changes, frequent
releases, etc true of so many projects I'm using. Cucumber sticks out by the
quality of its releases, and not in a good way. It can be done better, it's
just a question of deciding to make an effort.

Wouldn't you expect a test tool to, itself, use the best practices, pay
attention to testing, worry about quality assurance of the entire lifecycle
of each release? What example would you want to set?

And last, successful open source projects are asked to grow up before
they're done with chaos. That, in no way means you have to stop innovating,
going in new directions, even embarking on a top-down rewrite. You can be a
dependable, reliable solution and be working on the next big change at the
very same time.

Assaf

Post by Assaf Arkin
There's no need to defend an ad hoc release process, or teach me how to
use Git. A simple "not ready for production yet" would suffice.

Saying whether or not it's ready for production is impossible without
taking context into consideration. Plenty of people use Cucumber on real
systems that are in production. It boils down cost/benefit. If the total
benefit you get from increased quality with Cucumber scenarios outweigh the
cost of occasional upgrade-related problems? And is this cost/benefit more
favorable than an alternative to Cucumber?
If so, use it. If not, don't. Only you can decide what makes sense for you.
And things will get better with time.

Post by Assaf Arkin
Assaf

Post by Mike Sassak
Mike

Post by Assaf Arkin
Assaf

Post by Mike Sassak
Compare the situation with Cucumber to the development of a major Linux
distro like Debian. They have stable, testing and unstable channels.
Cucumber doesn't have enough active members to support anything like this,
so it's up to the developer to find a known stable version and make sure
you're always developing with that version. If you run into bugs in the
library you're using and need to upgrade, when you upgrade you yourself need
to simulate something like the path a library would take in a project like
Debian: from unstable to testing to stable. That takes time, but there's no
replacement for it.
Having said all that, it certainly *feels* like the 0.3.x series has
been going on forever--though I readily admit I have no numbers to back this
up--but I wonder, nevertheless, if that's not contributing to people
expecting smoother upgrades. I think going back to less frequent releases on
Rubyforge would help. Perhaps even adopting an even/stable odd/unstable
policy as well. The Linux kernel (used) to do this, and I think it works
pretty well without causing too many headaches.
Mike

Post by Stephen Eley
--
Have Fun,
ESCAPE POD - The Science Fiction Podcast Magazine
http://www.escapepod.org

Stephen Eley

2009-09-29 14:45:13 UTC

If you want to use story-focused BDD, this sort of begs the question
of what else you'd use. One of the reasons I think it's _appropriate_
that Cucumber's in flux is because it's pioneering. It's not trying
to compete against others in its niche. It's inventing the niche.
That we're along for the ride is a positive side effect of open source
agile development.

Post by Assaf Arkin
There's no need to defend an ad hoc release process, or teach me how to use
Git. A simple "not ready for production yet" would suffice.

One other mitigating factor: Cucumber isn't used in production. The
final end users of the application will never see it. It's used in
test. Developers and clients will see it -- and only developers need
to deal with these sorts of hassles.

Any developer for any active, living framework should already be used
to riding some transition curves. Just look at the seismic waves when
Rails puts out a point release. That doesn't mean the transition
needs to be pure chaos and uncertainty, or that a more cautious
versioning scheme is an unreasonable thing to ask for. It just means
"ready to use" is a different value for this audience than "ready for
production."
--
Have Fun,
Steve Eley (sfeley-***@public.gmane.org)
ESCAPE POD - The Science Fiction Podcast Magazine
http://www.escapepod.org

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Cukes" group.
To post to this group, send email to cukes-/***@public.gmane.org
To unsubscribe from this group, send email to cukes+unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/cukes?hl=en
-~----------~----~----~----~------~----~------~--~---

Assaf Arkin

2009-09-29 17:14:44 UTC

Post by Stephen Eley

Post by Assaf Arkin
I'm trying to decide if Cucumber has reached the point where I can take

Post by Assaf Arkin
seriously, depend on it and recommend it to others, or I should just let

Post by Assaf Arkin
go and find something else to use.

Post by Assaf Arkin
There's no need to defend an ad hoc release process, or teach me how to

use

Post by Assaf Arkin
Git. A simple "not ready for production yet" would suffice.

It's used by me to test features before shipping them out. As a double
measure, both while developing and continuous integration server. No release
unless it's all green.

That's use in production.

Imagine that your test tool all of a sudden decides to let some broken tests
pass. Just because. Your end user doesn't see the "all green" report, that's
true, but they do see all the bugs introduced by a broken test tool. When a
test tool is used to certify a release, it's effectively used in production.

Assaf

Post by Stephen Eley
--
Have Fun,
ESCAPE POD - The Science Fiction Podcast Magazine
http://www.escapepod.org

Stephen Eley

2009-09-29 19:58:11 UTC

Post by Assaf Arkin
Imagine that your test tool all of a sudden decides to let some broken tests
pass. Just because. Your end user doesn't see the "all green" report, that's
true, but they do see all the bugs introduced by a broken test tool. When a
test tool is used to certify a release, it's effectively used in production.

First: I haven't seen Cucumber exhibit that sort of problem. I
realize that's not your point, you're expressing a hypothetical, but
it's a problem of a different nature than the annoyances listed so
far.

Second: Is an all-green on Cucumber your _only_ criterion for
releasing into production? In my workflow, it's just one tool on my
toolbelt. I also use RSpec, _occasionally_ I'll use Selenium's
browser recording thing, once or twice I've written one-off scripts
for data verification, and -- most of all -- I use my own eyes. If I
just added a cool new feature, I want to *see it work*. I'm going to
poke around with it for a while, if only because it's fun to see stuff
that I made in action.

Sure, eyeballs aren't as consistent as continuous integration. I
might miss some regression in an area I wouldn't think to look at, and
RSpec might miss it because it's at the interface between units rather
than within a unit, and it might slip through every other crack. If I
had a valid Cucumber test for that regression, and Cucumber missed it
due to a bug, I'd be righteously annoyed. It could happen. Every
dependency creates risk.

But I haven't seen any evidence yet that it's likely. And I haven't
found a feature design and integration test tool that I'd _rather_ use
than Cucumber. So I put up with the transition annoyances and I make
suggestions. It's within my risk tolerance. If it's outside of
yours, I would (sincerely!) be interested in knowing what you're
thinking of using instead.
--
Have Fun,
Steve Eley (sfeley-***@public.gmane.org)
ESCAPE POD - The Science Fiction Podcast Magazine
http://www.escapepod.org

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Cukes" group.
To post to this group, send email to cukes-/***@public.gmane.org
To unsubscribe from this group, send email to cukes+unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/cukes?hl=en
-~----------~----~----~----~------~----~------~--~---

Assaf Arkin

2009-09-29 22:28:22 UTC

Post by Stephen Eley

Post by Assaf Arkin
Imagine that your test tool all of a sudden decides to let some broken tests
pass. Just because. Your end user doesn't see the "all green"
report, that's
true, but they do see all the bugs introduced by a broken test tool. When a
test tool is used to certify a release, it's effectively used in production.

First: I haven't seen Cucumber exhibit that sort of problem. I
realize that's not your point, you're expressing a hypothetical, but
it's a problem of a different nature than the annoyances listed so
far.
Second: Is an all-green on Cucumber your _only_ criterion for
releasing into production? In my workflow, it's just one tool on my
toolbelt. I also use RSpec, _occasionally_ I'll use Selenium's
browser recording thing, once or twice I've written one-off scripts
for data verification, and -- most of all -- I use my own eyes. If I
just added a cool new feature, I want to *see it work*. I'm going to
poke around with it for a while, if only because it's fun to see stuff
that I made in action.
Sure, eyeballs aren't as consistent as continuous integration. I
might miss some regression in an area I wouldn't think to look at, and
RSpec might miss it because it's at the interface between units rather
than within a unit, and it might slip through every other crack. If I
had a valid Cucumber test for that regression, and Cucumber missed it
due to a bug, I'd be righteously annoyed. It could happen. Every
dependency creates risk.
But I haven't seen any evidence yet that it's likely. And I haven't
found a feature design and integration test tool that I'd _rather_ use
than Cucumber. So I put up with the transition annoyances and I make
suggestions. It's within my risk tolerance. If it's outside of
yours, I would (sincerely!) be interested in knowing what you're
thinking of using instead.

Eye balls, rspec, cucmber, staging, beta testing, autotest, CI, daily
metric_fu reports, topic branches, code review, one feature per
release, separate bug-fix/feature release, stanby window, hourly/daily/
weekly backup, etc.

Standard fair if you want to minimze number, severity and duration of
bugs affecting users.

The quality of features I release depends on the quality of the code,
the process and the tools I use.

There's no reason a test tool will flag broken tests as passing.
There's no reason for HTML formatter to require ruby-debug, or for a
longtime outstanding regex bug to only affect one release. Yet the
last two did happen. Bugs are thing you naturally didn't expect to go
wrong, murphy's law is on their side.

The question is what do you do about bugs. What's your policy for
reducing their frequency and severity?

Either you pay attention to the quality of releases, or you let
anything pass. There's no middle way.

Above all, test tools must be reliable. If the test tool is
unreliable, so are your tests and so is the code you're shipping.

I, for one, do not consider depending on an "it works when it works"
test tool part of my test methodology. I don't see how it benefits
code quality, and I'm not aware of other valid reason to test.

Assaf

Post by Stephen Eley
--
Have Fun,
ESCAPE POD - The Science Fiction Podcast Magazine
http://www.escapepod.org

Andrew Premdas

2009-10-01 00:27:01 UTC

Post by Stephen Eley

First: I haven't seen Cucumber exhibit that sort of problem. I
realize that's not your point, you're expressing a hypothetical, but
it's a problem of a different nature than the annoyances listed so
far.
Second: Is an all-green on Cucumber your _only_ criterion for
releasing into production? In my workflow, it's just one tool on my
toolbelt. I also use RSpec, _occasionally_ I'll use Selenium's
browser recording thing, once or twice I've written one-off scripts
for data verification, and -- most of all -- I use my own eyes. If I
just added a cool new feature, I want to *see it work*. I'm going to
poke around with it for a while, if only because it's fun to see stuff
that I made in action.
Sure, eyeballs aren't as consistent as continuous integration. I
might miss some regression in an area I wouldn't think to look at, and
RSpec might miss it because it's at the interface between units rather
than within a unit, and it might slip through every other crack. If I
had a valid Cucumber test for that regression, and Cucumber missed it
due to a bug, I'd be righteously annoyed. It could happen. Every
dependency creates risk.
But I haven't seen any evidence yet that it's likely. And I haven't
found a feature design and integration test tool that I'd _rather_ use
than Cucumber. So I put up with the transition annoyances and I make
suggestions. It's within my risk tolerance. If it's outside of
yours, I would (sincerely!) be interested in knowing what you're
thinking of using instead.

Eye balls, rspec, cucmber, staging, beta testing, autotest, CI, daily
metric_fu reports, topic branches, code review, one feature per
release, separate bug-fix/feature release, stanby window, hourly/daily/
weekly backup, etc.
Standard fair if you want to minimze number, severity and duration of
bugs affecting users.
The quality of features I release depends on the quality of the code,
the process and the tools I use.
There's no reason a test tool will flag broken tests as passing.
There's no reason for HTML formatter to require ruby-debug, or for a
longtime outstanding regex bug to only affect one release. Yet the
last two did happen. Bugs are thing you naturally didn't expect to go
wrong, murphy's law is on their side.
The question is what do you do about bugs. What's your policy for
reducing their frequency and severity?
Either you pay attention to the quality of releases, or you let
anything pass. There's no middle way.
Above all, test tools must be reliable. If the test tool is
unreliable, so are your tests and so is the code you're shipping.
I, for one, do not consider depending on an "it works when it works"
test tool part of my test methodology. I don't see how it benefits
code quality, and I'm not aware of other valid reason to test.
Assaf

Post by Stephen Eley
--
Have Fun,
ESCAPE POD - The Science Fiction Podcast Magazine
http://www.escapepod.org

Jeez Assaf you're giving people a really hard time here. Cucumber is

wonderful tool and personally I am really grateful for all the hard (unpaid)
work that is done on it. In the past few point releases it has gracefully
dealt with quite important issues regarding switching off transactions and
rails error handling. Both these changes broke my current build, but reading
the history file and working through the changes has left me with a much
better suite of features. Yes I've had to do a bit of work to deal with this
but the reward that cucumber has given me by addressed elegantly two major
issues that I only brought up a couple of weeks ago is frankly wonderful.
Yes there are some issues caused by the speed of development of cucumber and
mistakes have been made and admitted. But lets not forget the big picture
here - Cucumber has taken RSpec plain text stories and transformed them from
being a slightly weird part of the RSpec suite to a mainstream tool
supporting a rapidly growing multinational community of developers. This is
a major achievement worthy of celebration. If you wish this to continue I
would suggest supporting the people here that do the work that you are
benefiting from.

At the moment the last thing this project needs is additional layers of
bureaucracy slowing innovation and improvement, and placing an increased
burden and pressure on the people who are making Cucumber such a great tool.
Cucumber also does not need users that demand, it needs users that
contribute, I am sure with your knowledge a small change of tone you could
be one of these contributers.

Andrew

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Cukes" group.
To post to this group, send email to cukes-/***@public.gmane.org
To unsubscribe from this group, send email to cukes+unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/cukes?hl=en
-~----------~----~----~----~------~----~------~--~---

Assaf Arkin

2009-10-01 06:29:38 UTC

Post by Assaf Arkin
Jeez Assaf you're giving people a really hard time here. Cucumber is
wonderful tool and personally I am really grateful for all the hard
(unpaid) work that is done on it. In the past few point releases it
has gracefully dealt with quite important issues regarding switching
off transactions and rails error handling. Both these changes broke
my current build, but reading the history file and working through
the changes has left me with a much better suite of features. Yes
I've had to do a bit of work to deal with this but the reward that
cucumber has given me by addressed elegantly two major issues that
I only brought up a couple of weeks ago is frankly wonderful.
Yes there are some issues caused by the speed of development of
cucumber and mistakes have been made and admitted. But lets not
forget the big picture here - Cucumber has taken RSpec plain text
stories and transformed them from being a slightly weird part of the
RSpec suite to a mainstream tool supporting a rapidly growing
multinational community of developers. This is a major achievement
worthy of celebration. If you wish this to continue I would suggest
supporting the people here that do the work that you are benefiting
from.
At the moment the last thing this project needs is additional layers
of bureaucracy slowing innovation and improvement, and placing an
increased burden and pressure on the people who are making Cucumber
such a great tool. Cucumber also does not need users that demand, it
needs users that contribute, I am sure with your knowledge a small
change of tone you could be one of these contributers.

I disagree. I think Cucumber is good enough that the world should
start using it en masse. All the tinkering going on since 0.3.90 is
not making a significant improvement to Cucumber's world readiness,
just establishing a reputation of an immature, unreliable project with
fear of committing to a 1.0 release.

I've seen fear of commitment ruin projects that had tremendous
potential, just not the drive to realize it. "Release early, release
often" is about pushing code to source control, but it's also about
making final public releases.

We're all grateful for the wonderful work other people are doing and
we can benefit from. We feel that open source is intrinsically better
for being open and a free. It's underdog, developed with no corporate
budget. And, don't you just hate it when people feel entitled and
start demanding something from software they never paid for?

That's where the instinct of jumping to the defense of an open source
project comes from. But it's wrong. Defending open source projects
doesn't make them better. Making them better does.

Detractors of open source say "it's only free if your time is not
worth anything". Do you think they're right? Are you doing anything to
prove them wrong?

As an open source developer, two of the best lessons I learned (the
heard way, if you have to ask) are:
- Shipping is the most important feature.
- Listen to your users.

Assaf

Post by Assaf Arkin
Andrew

aslak hellesoy

2009-10-01 07:02:11 UTC

Post by Assaf Arkin
Jeez Assaf you're giving people a really hard time here. Cucumber is
wonderful tool and personally I am really grateful for all the hard (unpaid)
work that is done on it. In the past few point releases it has gracefully
dealt with quite important issues regarding switching off transactions and
rails error handling. Both these changes broke my current build, but reading
the history file and working through the changes has left me with a much
better suite of features. Yes I've had to do a bit of work to deal with this
but the reward that cucumber has given me by addressed elegantly two major
issues that I only brought up a couple of weeks ago is frankly wonderful.
Yes there are some issues caused by the speed of development of cucumber
and mistakes have been made and admitted. But lets not forget the big
picture here - Cucumber has taken RSpec plain text stories and transformed
them from being a slightly weird part of the RSpec suite to a mainstream
tool supporting a rapidly growing multinational community of developers.
This is a major achievement worthy of celebration. If you wish this to
continue I would suggest supporting the people here that do the work that
you are benefiting from.
At the moment the last thing this project needs is additional layers of
bureaucracy slowing innovation and improvement, and placing an increased
burden and pressure on the people who are making Cucumber such a great tool.
Cucumber also does not need users that demand, it needs users that
contribute, I am sure with your knowledge a small change of tone you could
be one of these contributers.
I disagree. I think Cucumber is good enough that the world should start
using it en masse. All the tinkering going on since 0.3.90 is not making a
significant improvement to Cucumber's world readiness, just establishing a
reputation of an immature, unreliable project with fear of committing to a
1.0 release.

I've been holding off with a major release because I'm not comfortable with
several of the APIs. If we had gone prematurely to 1.0 it would have been
much harder to change them because we'd have to pay much more attention to
backwards compatibility.

So still staying at a low version number gives us that freedom to improve
internals and APIs.

I bumped up to .90 when I thought we were close to 0.4, but then lots of
feature requests cam along and I realised that upping the release number
would make it harder to deal with these requests.

Post by Assaf Arkin
I've seen fear of commitment ruin projects that had tremendous potential,
just not the drive to realize it. "Release early, release often" is about
pushing code to source control, but it's also about making final public
releases.

You seem to think Cucumber is ready for 1.0. It's not - trust me. I don't
have fear of commitment - I'm really committed. I just don't want to give
people a false sense of security by calling something a 1.0 when I know
there will be more big changes.

People always bitch when stuff breaks. Some more than others wink wink. I'm
more comfortable that people bitch about a broken 0.3 release than a broken
1.0 release.

Post by Assaf Arkin
We're all grateful for the wonderful work other people are doing and we can
benefit from. We feel that open source is intrinsically better for being
open and a free. It's underdog, developed with no corporate budget. And,
don't you just hate it when people feel entitled and start demanding
something from software they never paid for?
That's where the instinct of jumping to the defense of an open source
project comes from. But it's wrong. Defending open source projects doesn't
make them better. Making them better does.
Detractors of open source say "it's only free if your time is not worth
anything". Do you think they're right? Are you doing anything to prove them
wrong?
As an open source developer, two of the best lessons I learned (the heard
- Shipping is the most important feature.
- Listen to your users.

I heard you the first time Assaf. You got your point across.

Post by Assaf Arkin
Assaf
Andrew

Andrew Premdas

2009-10-01 08:03:31 UTC

Post by Assaf Arkin
Jeez Assaf you're giving people a really hard time here. Cucumber is
wonderful tool and personally I am really grateful for all the hard (unpaid)
work that is done on it. In the past few point releases it has gracefully
dealt with quite important issues regarding switching off transactions and
rails error handling. Both these changes broke my current build, but reading
the history file and working through the changes has left me with a much
better suite of features. Yes I've had to do a bit of work to deal with this
but the reward that cucumber has given me by addressed elegantly two major
issues that I only brought up a couple of weeks ago is frankly wonderful.
Yes there are some issues caused by the speed of development of cucumber
and mistakes have been made and admitted. But lets not forget the big
picture here - Cucumber has taken RSpec plain text stories and transformed
them from being a slightly weird part of the RSpec suite to a mainstream
tool supporting a rapidly growing multinational community of developers.
This is a major achievement worthy of celebration. If you wish this to
continue I would suggest supporting the people here that do the work that
you are benefiting from.
At the moment the last thing this project needs is additional layers of
bureaucracy slowing innovation and improvement, and placing an increased
burden and pressure on the people who are making Cucumber such a great tool.
Cucumber also does not need users that demand, it needs users that
contribute, I am sure with your knowledge a small change of tone you could
be one of these contributers.
I disagree. I think Cucumber is good enough that the world should start
using it en masse. All the tinkering going on since 0.3.90 is not making a
significant improvement to Cucumber's world readiness, just establishing a
reputation of an immature, unreliable project with fear of committing to a
1.0 release.

Actually the @no-txn and @allow-rescue stuff were significant improvements
to Cucumber.

My experience is pretty limited using open source stuff for only about 10
years. During that time I really don't think I've seen a more committed and
responsive mailing list than the rspec and cucumber ones.

Post by Assaf Arkin
anything". Do you think they're right? Are you doing anything to prove them
wrong?

My personal views on open source aren't really relevant here

Post by Assaf Arkin
As an open source developer, two of the best lessons I learned (the heard
- Shipping is the most important feature.
- Listen to your users.
Assaf

Post by Assaf Arkin
~----------~----~----~----~------~----~------~--~---

Assaf Arkin

2009-10-01 08:27:13 UTC

Post by Assaf Arkin
Jeez Assaf you're giving people a really hard time here. Cucumber
is wonderful tool and personally I am really grateful for all the
hard (unpaid) work that is done on it. In the past few point
releases it has gracefully dealt with quite important issues
regarding switching off transactions and rails error handling. Both
these changes broke my current build, but reading the history file
and working through the changes has left me with a much better
suite of features. Yes I've had to do a bit of work to deal with
this but the reward that cucumber has given me by addressed
elegantly two major issues that I only brought up a couple of weeks
ago is frankly wonderful.
Yes there are some issues caused by the speed of development of
cucumber and mistakes have been made and admitted. But lets not
forget the big picture here - Cucumber has taken RSpec plain text
stories and transformed them from being a slightly weird part of
the RSpec suite to a mainstream tool supporting a rapidly growing
multinational community of developers. This is a major achievement
worthy of celebration. If you wish this to continue I would suggest
supporting the people here that do the work that you are benefiting
from.
At the moment the last thing this project needs is additional
layers of bureaucracy slowing innovation and improvement, and
placing an increased burden and pressure on the people who are
making Cucumber such a great tool. Cucumber also does not need
users that demand, it needs users that contribute, I am sure with
your knowledge a small change of tone you could be one of these
contributers.

Fear of commitment, not lack of commitment.

Post by Assaf Arkin
We're all grateful for the wonderful work other people are doing and
we can benefit from. We feel that open source is intrinsically
better for being open and a free. It's underdog, developed with no
corporate budget. And, don't you just hate it when people feel
entitled and start demanding something from software they never paid
for?
That's where the instinct of jumping to the defense of an open
source project comes from. But it's wrong. Defending open source
projects doesn't make them better. Making them better does.
I'm really not defending Cucumber, I'm being critical of your tone,
which is berating the people who develop cucumber. I'm not talking
about the points you are making but the way you are making them.
Your tone does nothing to make the project better its counter
productive

I think that the release process is bad. I don't think people on this
project are bad. If you're an excellent developer who does their very
best to follow a bad process you end up with less than stellar
results. That's not a reflect on who you are, but on the process you
follow. I have an issue with the process.

Post by Assaf Arkin
Detractors of open source say "it's only free if your time is not
worth anything". Do you think they're right? Are you doing anything
to prove them wrong?
My personal views on open source aren't really relevant here
As an open source developer, two of the best lessons I learned (the
- Shipping is the most important feature.
- Listen to your users.
Assaf
As a user of open source I've learnt that it is easy to criticise
and much harder to contribute. So personally I value contributions
over criticism. I think with a little bit of extra work and care,
your recent critiscisms could have been contributions, but in their
current form is really difficult to see them in that light.

As an open source developer I have learned that any contribution is
better than none. Criticism is what you offer when you don't have time
to contribute more significantly, but remember that the person
criticising your project now may be busy contributing to another
project you'll be using tomorrow. Open source is a distributed problem
solving, and you have to accept that some people are vested
contributing to other projects.

Assaf

Post by Assaf Arkin
Andrew

Post by Assaf Arkin
~----------~----~----~----~------~----~------~--~---

aslak hellesoy

2009-10-01 08:34:44 UTC

Post by Andrew Premdas

Post by Assaf Arkin
Jeez Assaf you're giving people a really hard time here. Cucumber is
wonderful tool and personally I am really grateful for all the hard (unpaid)
work that is done on it. In the past few point releases it has gracefully
dealt with quite important issues regarding switching off transactions and
rails error handling. Both these changes broke my current build, but reading
the history file and working through the changes has left me with a much
better suite of features. Yes I've had to do a bit of work to deal with this
but the reward that cucumber has given me by addressed elegantly two major
issues that I only brought up a couple of weeks ago is frankly wonderful.
Yes there are some issues caused by the speed of development of cucumber
and mistakes have been made and admitted. But lets not forget the big
picture here - Cucumber has taken RSpec plain text stories and transformed
them from being a slightly weird part of the RSpec suite to a mainstream
tool supporting a rapidly growing multinational community of developers.
This is a major achievement worthy of celebration. If you wish this to
continue I would suggest supporting the people here that do the work that
you are benefiting from.
At the moment the last thing this project needs is additional layers of
bureaucracy slowing innovation and improvement, and placing an increased
burden and pressure on the people who are making Cucumber such a great tool.
Cucumber also does not need users that demand, it needs users that
contribute, I am sure with your knowledge a small change of tone you could
be one of these contributers.
I disagree. I think Cucumber is good enough that the world should start
using it en masse. All the tinkering going on since 0.3.90 is not making a
significant improvement to Cucumber's world readiness, just establishing a
reputation of an immature, unreliable project with fear of committing to a
1.0 release.

to Cucumber.

I'm really not defending Cucumber, I'm being critical of your tone, which
is berating the people who develop cucumber. I'm not talking about the
points you are making but the way you are making them. Your tone does
nothing to make the project better its counter productive
I think that the release process is bad. I don't think people on this
project are bad. If you're an excellent developer who does their very best
to follow a bad process you end up with less than stellar results. That's
not a reflect on who you are, but on the process you follow. I have an issue
with the process.

Like I said. I heard you the first time. We have admitted mistakes and have
already taken measures to improve things (CI). But you just go on and on and
on and on about it, which is really fucking annoying. Saying that no
significant improvements have been made since 0.3.90 is bullshit.

Do us all (and yourself) a favour and STFU.

Aslak

Post by Andrew Premdas
Detractors of open source say "it's only free if your time is not worth

Post by Assaf Arkin
anything". Do you think they're right? Are you doing anything to prove them
wrong?

My personal views on open source aren't really relevant here

Post by Assaf Arkin
As an open source developer, two of the best lessons I learned (the heard
- Shipping is the most important feature.
- Listen to your users.
Assaf

As a user of open source I've learnt that it is easy to criticise and much
harder to contribute. So personally I value contributions over criticism. I
think with a little bit of extra work and care, your recent critiscisms
could have been contributions, but in their current form is really difficult
to see them in that light.
As an open source developer I have learned that any contribution is better
than none. Criticism is what you offer when you don't have time to
contribute more significantly, but remember that the person criticising your
project now may be busy contributing to another project you'll be using
tomorrow. Open source is a distributed problem solving, and you have to
accept that some people are vested contributing to other projects.
Assaf
Andrew

Post by Assaf Arkin
~----------~----~----~----~------~----~------~--~---

Jay Shepherd

2009-10-01 15:49:44 UTC

Post by Assaf Arkin
Jeez Assaf you're giving people a really hard time here. Cucumber is
wonderful tool and personally I am really grateful for all the hard (unpaid)
work that is done on it. In the past few point releases it has gracefully
dealt with quite important issues regarding switching off transactions and
rails error handling. Both these changes broke my current build, but reading
the history file and working through the changes has left me with a much
better suite of features. Yes I've had to do a bit of work to deal with this
but the reward that cucumber has given me by addressed elegantly two major
issues that I only brought up a couple of weeks ago is frankly wonderful.
Yes there are some issues caused by the speed of development of cucumber
and mistakes have been made and admitted. But lets not forget the big
picture here - Cucumber has taken RSpec plain text stories and transformed
them from being a slightly weird part of the RSpec suite to a mainstream
tool supporting a rapidly growing multinational community of developers.
This is a major achievement worthy of celebration. If you wish this to
continue I would suggest supporting the people here that do the work that
you are benefiting from.
At the moment the last thing this project needs is additional layers of
bureaucracy slowing innovation and improvement, and placing an increased
burden and pressure on the people who are making Cucumber such a great tool.
Cucumber also does not need users that demand, it needs users that
contribute, I am sure with your knowledge a small change of tone you could
be one of these contributers.
I disagree. I think Cucumber is good enough that the world should start
using it en masse. All the tinkering going on since 0.3.90 is not making a
significant improvement to Cucumber's world readiness, just establishing a
reputation of an immature, unreliable project with fear of committing to a
1.0 release.

improvements to Cucumber.

Post by Assaf Arkin
Detractors of open source say "it's only free if your time is not worth

Post by Assaf Arkin
anything". Do you think they're right? Are you doing anything to prove them
wrong?

My personal views on open source aren't really relevant here

Post by Assaf Arkin
As an open source developer, two of the best lessons I learned (the heard
- Shipping is the most important feature.
- Listen to your users.
Assaf

Post by Assaf Arkin
~----------~----~----~----~------~----~------~--~---

Matt Wynne

2009-09-29 15:03:34 UTC