[Rubygems-developers] Trunk version of rubygems should always be > released version
thewoolleyman at gmail.com
Thu Jun 25 03:02:50 EDT 2009
On Wed, Jun 24, 2009 at 8:06 PM, Ryan Davis<ryand-ruby at 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
* 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
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
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!"
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.
More information about the Rubygems-developers