[rspec-users] exemplary way to show a list is sorted?
nick at deadorange.com
Wed Feb 11 11:40:51 EST 2009
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 <lists at ruby-forum.com>
>>> David Chelimsky wrote:
>>>> please use "should be >=" as "should >=" will eventually be
>>>> and removed.
>>> Removed? You are not seriously contemplating forcing people to go
>>> and rewrite formally working specifications simply to tidy up the
>>> 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
> 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.
More information about the rspec-users