On 10/02/2009, at 10:09 PM, James Byrne wrote:
Zach Dennis wrote:
On Tue, Feb 10, 2009 at 6:22 PM, James Byrne <li...@ruby-forum.com>
wrote:
David Chelimsky wrote:
please use "should be >=" as "should >=" will eventually be
deprecated
and removed.
Removed? You are not seriously contemplating forcing people to go
back
and rewrite formally working specifications simply to tidy up the
syntax
are you?
Forcing people, eh? You don't have to upgrade when that release is
made. No one is holding a gun to your head. You can always choose to
progress with the library, as it continues to evolve into new and
better ways of doing things.
There are enterprises in which the stability of development tools and
the confidence that one will not be forced to redo work already
completed is considered somewhat important, whatever your own
situation
might be. Likewise, assuming the costs of maintaining a customized
variant of a general tool or foregoing future improvements in same to
maintain the value of existing work is not a choice savoured by many
firms that I can bring to mind, even if yours might be exceptional in
this regard. At issue is something commonly referred to as
cost/benefit, which ultimately turns into profit and loss.
I simply fail to see why evolving a tool in "better ways" necessarily
requires that the formerly "better" but now depreciated method be
removed. Such action causes avoidable and pointless work. I
consider my
observation to be both reasonable and pertinent.
I hear what you're saying, James, and agree with you to a certain
extent. However, one must keep a few things in mind:
1) The syntax in question will be valid, but deprecated, in all 1.x
releases. This means that you can continue to use the old syntax.
2) If you're willing to change which version of RSpec a project of
yours uses, then you must be willing to change how the project uses
RSpec. Change begets change.
3) When a new major version of a project is released, one must be
prepared for major changes. If the changes are incompatible with you
or your own software, several options exist:
3.1) Do not upgrade to the new major version.
3.2) Fork the new major version, add your desired modifications, then
use that fork in your software.
3.3) Modify your software so that it becomes compatible with the new
major version of the project in question.
4) Most free and/or open-source projects are run as democracies.
However, they are overseen by the lead maintainer(s), who have the
final say when it comes to making decisions. This is because they have
the most knowledge of, and experience with, the project, and
understand best the direction that the project should be going in.
Cheers,
Nick
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
