[Rubygems-developers] Prerelease Gems (was: Gem#status?)
technomancy at gmail.com
Thu Nov 13 12:52:33 EST 2008
"Luis Lavena" <luislavena at gmail.com> writes:
> There is already a big nightmare (not to say gem hell) related to
> preview/rc gems laying in github or rubyforge that complicate the
> environment of many users (I get several reports about that). As
> example I can mention rspec gem depending on a patched version of rcov
> that only exist in github and has no binaries for it.
Right now a lot of people keep prerelease gems on github only. This is
because there's no good way to handle them in Rubyforge. Currently if
someone installs a stable release of a gem (on github, or any source
that's been added) and then issues a "gem update" after a prerelease has
been pushed out, they will pull it in even if they want to stick with
the stable release. This problem will be alleviated if rubygems has a
way of distinguishing between stable releases and prereleases.
> I believe pushing RC or preview versions to rubyforge will make "gem
> update" for several users a nightmare.
This is exactly what I'm working on right now. It's not like we're just
tossing prerelease gems into a big pile and calling it done; we're
taking special care to make sure that they only get pulled in when
they're explicitly requested.
> Previously, no RC or preview gem was published to rubyforge.
That's not true; see Ryan's earlier post. Previously there's been no
sane way to handle prereleases, so everyone does it differently. Merb
has one way, Rails has another, other people make up their own. I've run
the idea by Rick Olson of Rails core, and he is in favour of
it. Everyone I mentioned it to at RubyConf was eager to see it
> Previews and RC where available through private gem servers to avoid
> this situation letting the developers control how and when these gems
> will hit the mirrors and made into the public.
But this also means that nobody can offer prerelease gems unless they're
willing to run their own gem servers (or willing to seriously confound
the users of their gems.) If Rubyforge can offer this service, it will
level the playing field for smaller projects.
> I don't see big OS distros like Ubuntu or even debian opening the room
> for RC and preview packages to their official distribution
Oh, don't they? (http://p.hagelb.org/prerelease.png)
Even if that weren't the case, there are a lot of things apt-get doesn't
do that we do, like allowing multiple versions of a gem to be installed
at the same time. If we were to blindly follow their lead, we would lose
a lot of really useful functionality. Gems have a *much* more rapid pace
of change than debs do; it's only natural that the infrastructure should
> Anyway, just my PoV, this will also render useless patterns like "~>"
> and even worse dumb developers that do not check or maintain their
> dependency list properly.
Actually, the whole point of this is to *fix* the usage of ~> for
prereleases. Right now if you want to depend on version 0.9 of Merb, you
will pull in their 1.0 RC, because its version is 0.9.99 or some such. A
lot of projects use this versioning scheme, and it renders
major-version-only matching useless.
If you read carefully over the proposed solution and can come up with a
real flaw in it, then *please* bring it up. If you've found some edge
case that I haven't thought of, I'm all ears. But vague fears and doubts
really do very little to help the situation.
That said, I'm willing to defer to Eric's judgment if he can find merit
in any of the objections that have been raised.
More information about the Rubygems-developers