On Wed, Jun 24, 2009 at 8:06 PM, Ryan Davis<ryand-r...@zenspider.com> wrote: > I've been watching it go by and the only > word that comes to mind consistently is "mentarbation".
Cute term. However, repeated refusal to answer a question directly begets verbosity. If you don't want me to keep explaining myself in greater and greater detail, don't keep ignoring clearly stated points and making irrelevant responses and suggestions. Also, this thread would not have existed past my single courtesy post if you hadn't rolled back my two-character commit in the first place. Other comments (verbose yet still carefully chosen after *reading* your email - hint hint): * You still never described any problems this would cause for your development model, or why it matters at all to you. * I *already* do what multiruby does - I freeze selected major *released* versions of RubyGems in version-named directories and can run dedicated CI projects against them. That has nothing to do this issue. * No, I don't care about parsing or distinguishing different revisions of trunk, because they are not released. They are all the same to me for purposes of API compatibility checks: "> last_release". That has nothing to do with this issue either. * "Doing more than that is not a good use of our time." You don't even have to do it yourselves, Eric gave me commit rights a while back (unless you get pissed and revoke it). I use this to help out as I can, running CI and (very) occasional patches, and I always try to be very diligent with good Changelog comments, etc. That's what I was originally trying to do in this thread... * "Please. Drop it. Let's get on to more useful things." I considered that, but then decided against it, since you still have not shown that you understand the issue, and are telling me to go write some unnecessary and overly complex code. That justifies further discussion in my book. This is a development list, after all. Anyone who doesn't care about this topic should have hit mute in gmail a long time ago. Let me explain, verbosely, yet again: The main point here is for an API client to be able to tell what version of code it is running against. That is a *requirement* for properly managing backward and forward compatibility. If you break the API for me, I want my client to *conditionally* execute code to handle that. I want to add that client code immediately and proactively, as soon as you break the API, so I'm ready to release my client update as soon as (ideally before) you release the API. I want my conditional compatibility code to only run on *future* releases - NOT the current release, because the API is not broken in the current release. The logical way to do that is to have a *different* version for the current and the future API release. The current and future release are not the same code; my client does not interact with them in the same way; therefore they should not have the same version. Freezing old versions and parsing revisions in future release do not solve this problem - I can't do that in my client code, and there's no reason to do it in my test code. What does solve these problems, simply, and correctly, is *comparing* versions. You can only compare versions if they are different. There is a simple method built into rubygems for exactly this purpose: Gem::Version::Requirement#satisfied_by? I don't know how many other different ways I can explain it, so I'll stop. Here's my paraphrase of the tone of your note: "We won't allow you to commit two characters after each release. These changes don't make any difference to our "developement model", or even matter to us at all, but we are still refusing because we are in control. Instead, go write some unnecessary and complex code in your own API client and tests." The phrase that comes consistently to MY mind is a quote I heard from Evan Phoenix: "You are not the project, Mr. Ego!" http://pivotallabs.com/users/chad/blog/articles/category/152-mtnwestrubyconf Anyway, no hard feelings. Just being an OCD programmer and trying to get you to understand my point. You do a lot of great stuff, especially all the metrics tools. I'm in awe of Eric too, the stuff he's done for RubyGems and Ruby is huge. Great job. Thanks, -- Chad _______________________________________________ Rubygems-developers mailing list http://rubyforge.org/projects/rubygems Rubygems-developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers
