' however with a symbol it works great. Thanks! -rp ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28024&group_id=126 From noreply at rubyforge.org Tue Mar 30 10:12:57 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 30 Mar 2010 10:12:57 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-28033 ] gem unpack fails as non-privileged user Message-ID: <20100330141257.312AF18582C9@rubyforge.org> Bugs item #28033, was opened at 2010-03-30 23:12 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28033&group_id=126 Category: `gem` commands (other) Group: None Status: Open Resolution: None Priority: 3 Submitted By: Mathieu Sauve-Frankel (kisoku) Assigned to: Nobody (None) Summary: gem unpack fails as non-privileged user Initial Comment: Rubygems::Installer when called with options[:unpack] will always attempt to create the default gem directory, even when running as a non-privileged user. As Rubygems::Commands::UnpackCommand does not have the --user-install option included, it is not longer possible to unpack gems as a user who does not have write access to @gem_home. See line 136 of lib/rubygems/installer.rb ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28033&group_id=126 From jftucker at gmail.com Wed Mar 31 06:05:49 2010 From: jftucker at gmail.com (James Tucker) Date: Wed, 31 Mar 2010 11:05:49 +0100 Subject: [Rubygems-developers] Rubygems Packaging Enhancements and Designs In-Reply-To: References: Message-ID: <38F0B358-9035-4691-8D1A-DE82AB60AC0D@gmail.com> On 31 Mar 2010, at 10:02, Hugh Sasse wrote: > [...] >> that starts. The only way to move forward is to understand, and > In that spirit, I'd like to contribute the following. > [...] >> * Fresh documentation for teams packaging rubygems and gems inside >> other package managers * A set of platform test infrastructure > [...] > I'd like to point out that > > http://docs.rubygems.org/ > > could do with an update. It refers to rubygems 0.8.7, and it says > that 1.3.x is in progress. Those (being updated) docs don't appear > to be visible to doc maintainers who wish to contribute. Could they > be released for maintenance? At present this is database backed I believe. That means you will want to sign up for an account and Eric can open it up for you. Alternatively, you could send patches to this ML and I can patch it for you. I want to spend time on that at some point, but it's lower on the priority list. I agree that moving it to something like asciidoc or the like and putting it in a repository might "open up" access for more people. > The importance of this is that a Google search for RubyGems > Documentation presents this as the first choice, so it is > a place many people will be looking for this. I agree 100%. I have already created a book on rubygems packaging at the site, that is currently empty and unpublished, but it will come to contain the guide that will be one of the results of the subproject in question. > It could also be worth collecting a critical bibliography of > published books that discuss how to use RubyGems, with a view > to describing how current the information in them is. Mostly it needs to be clear (and documented) that for users, rubygems is well self-documented: gem help gem help commands From jftucker at gmail.com Wed Mar 31 06:00:20 2010 From: jftucker at gmail.com (James Tucker) Date: Wed, 31 Mar 2010 11:00:20 +0100 Subject: [Rubygems-developers] Rubygems Packaging Enhancements and Designs In-Reply-To: References: Message-ID: <9A02ED39-C95A-4206-BDD0-1F22461A2706@gmail.com> Now look guys, I don't want to deal with crap like this. Grow up, or release your maintenance positions to me. You can't maintain these packages or help with their development unless you're willing to get involved. Step up, or step down, it's that simple. As I say below, I don't want to be angry, but a little give and take, rather than you guys breaking every single communication channel I try to open is the only way I can start to fix things. That's a fact of communication, it's a two way process that requires a common transport medium, and I am NOT willing to be a manual email hub just because you're being resistant, I'm putting enough time in trying to arbitrate already. Sadly, it's likely that if this warning is not received with a mature view, then this effort may fail before it's even really begun, in which case, I'll be dealing with the SUSE folks only, as they seem to be the only ones not nit-picking over communications, methods and mediums; instead they're working with me, promptly, and providing plenty of help, even infrastructure. They're on my gold list. Mails like below push you toward the .... list, for exceedingly obvious reasons. Finally, if you don't agree, please sleep on it, maybe for a week, then come back. If you still feel raw about it, then like I say, give up your maintenance positions, and walk away. I'm not having these arguments *again*, as neither of you can provide a real rationale behind your resistance. Current open channels: Direct email - please don't use this for design input, as I need everyone to be on the same channel for that. Mailing list - sign up, or step down. Wiki - to keep a central record of longer term decisions, avoiding bikeshed discussion and so on. I want this to be a summary of the facts. I could move this elsewhere, but I'd have to sign up, and so would the rest of the rubygems core team (who are already signed up on github, all of them, for a long time now). IRC - #rubygems and talking to me directly on freenode (raggi) is fine, although once again, this is purely for a realtime channel, facts need to be persisted to the wiki. Now I can open up more wiki's at other places (but at least one of us is going to have to give and sign up for anywhere else that's spam resistant). I can open up more IRC channels, but that's not persistent, and not suitable for the long term stuff. I can provide access to Campfire, or Talkerapp, or Teamvox, or etherpad, or a gist, or rubyforge wikis, or, or, or, or. They all have something in common, someone out of the lot of you, or more, is going to have to pull a finger out and sign up. I made a proactive set of (sane) choices based on (good) evidence for what is (commonly) available to our (main) userbase and (all) our maintainers. You're with us, or not. If not, once again, please step down. I'm willing to listen to rational arguments against my choices, but not being signed up to the rubygems ML when you're responsible for maintaining ports of rubygems packages as non-rubygems or not signing up to github because you're "not sure of the ramifications" are both truly pathetic reasons, and if you feel strongly about those two things you really shouldn't be holding any maintenance positions on these projects, because not doing so leaves you without suitable infrastructure to do so. More than that it should be against maintenance policies of distributions to be so disconnected and irresponsible. On 31 Mar 2010, at 06:36, Lucas Nussbaum wrote: > FYI. It might be better to keep the discussion off-list, then. > > - Lucas NO. You're involved with rubygems development, whether you like to admit it or not, you need to be on that ML. I'd dig up Debian policies about responsible administration of packages, but you guys are supposed to know those already. On 31 Mar 2010, at 10:02, Hugh Sasse wrote: > I can't seem to edit this without a github account. I've not > worked out all the ramifications of that yet, so not chosen a > package for github. I know Wikis can't be totally open because > of what happened to RubyGarden. Hopefully there's a way around > this. I don't know what the Venn diagram would look like for > wanted contributors and those that have github accounts. I've counted to 10. I've tried really hard to squash the feeling that you're nit-picking. I've tried to understand a rational reason of where you're coming from. I don't get it, and whilst I agree with everything else you've said in the mail, my reply to this is presently "grow up". Security is no excuse. Mail volume is no excuse. Professionalism is no excuse. Cost is no excuse (it's free). Remember please: HELP ME TO HELP YOU. There are limits to my time and effort on this and discussing philosophical lies about signing up for accounts on MASSIVE well known services is NOT what I am here for. http://github.com/blog/620-committing-like-crazy They handle 10x more open source commits per day than SourceForge, so like I say, grow up, sign up, and lets get down to some /real work/. Enough said, I'm very sorry if you find this mail upsetting, but you hit a bad button here, as the Debian folks are also currently trying to make me move off the rubygems ML too, because they don't want to sign up. It's PATHETIC, people are nit picking at stuff that's totally irrelevant, and it seems that they're either insane, evangelists, or just trying to wind me up and demoralise my effort to really fix this stuff. I'm here to fix rubygems, not people attitudes. Maturity and professionalism from here on in please, I don't want to be angry anymore. And YES I've been asked to sign up to places plenty of times in professional environments, and I don't give clients hell over it, it's bad for business and bad for karma. http://help.github.com/terms/ http://help.github.com/privacy/ Questions to: support at github.com From jftucker at gmail.com Wed Mar 31 06:54:01 2010 From: jftucker at gmail.com (James Tucker) Date: Wed, 31 Mar 2010 11:54:01 +0100 Subject: [Rubygems-developers] Rubygems Packaging Enhancements and Designs In-Reply-To: <20100330211642.GA31687@xanadu.blop.info> References: <20100330211642.GA31687@xanadu.blop.info> Message-ID: On 30 Mar 2010, at 22:16, Lucas Nussbaum wrote: > On 25/03/10 at 14:46 +0000, James Tucker wrote: > >> So after another hairy discussion on various lists, IRC channels and what not, I'm getting the urge to try and fix this for reals this time around. In an effort to do this, I'm dropping the ever so popular agile approach. This is a platform heavy issue, so I need better specs about platform specific requirements. That requires input from you guys, and from anyone else in a similar position. Spec collection is to happen on this wiki page, and I've started a small template of the discussion already. My lunch hour is coming to an end though, so there's plenty more to be added. Please add your opinions, requirements, design level bugs and so on, and I'll do what I can to distill this all down into a set of requirements that I can produce patches against. >> >> http://wiki.github.com/jbarnette/rubygems/packaging-designs >> >> As a sort of aside, I'm doing this to fix these problems as best as possible, and as such, I'm simply going to ignore any flame war that starts. The only way to move forward is to understand, and that's my intention, so please, I implore you all, explain your position clearly, rather than making demands, and whatever history you have is unimportant now, we're moving forward. >> >> If you know other maintainers that were not included in this email, please do forward this on to them, I need as much info as possible about what peoples requirements are in order to satisfy as many of them as possible in as few patches as possible. >> >> The final stages of this process should result in: >> >> * Fresh documentation for teams packaging rubygems and gems inside other package managers >> * A set of platform test infrastructure wired to build / commit / gem push hooks allowing us to be more proactive about these issues in future (the SUSE team have some great tools here, and a lot of domain knowledge already) >> * An agreeable attitude and platform for open discussion of these issues >> >> A quick word of warning about expectations. I'm not looking to move really fast on this. We need to get it right, and we need to avoid adding bugs as we do it, that's going to require /real/ and /extensive/ manual testing and a mature approach. Expecting fixes next month is not the intention here. What I do expect is that we can have standard ways to get this stuff off the ground, and reduce support requests for all related projects, with releases in most of your platforms hopefully by next year. > > So, to start things off, I'll clarify what we do in Debian. We do not > package gems (as in: libraries distributed as .gem files, for > installation with rubygems). > > Instead, we package ruby libraries. Usually, this is done by using the > .tgz provided by the upstream developers (the library's developers), or > using a service that allows us to fetch a specific tag from github as a > .tgz. That's ok for some packages, but absolutely not ok for others. > However, we provide a rubygems package in Debian, for users who want to > install gems manually. Yup. > So, our interest in this discussion is (in no particular order): > - to improve the rubygems package where possible, thus improving the > user experience for its users [ I'm not directly involved in the > rubygems packaging, but daigo at debian.org (Cced) is ] RubyGems is actually integral to ruby now, and as such, in many ways it should no longer be separated. I think a more sane way to look at this is that Ruby + RubyGems is a single platform, and it's heading that way, especially with gem_prelude in 1.9. I would like to get to the point where we have sufficient support and infrastructure that this merge is no longer a point of contention. I think if you'll bear with me, I can manage that too. > - to improve the awareness of our needs in the rubygems community You need to inform me, on this round, primarily, as this will be the largest push in this direction to date, and provided we can keep discussion moving forward in a sane way, I will succeed. This is also why I have put a 1 year timescale on my approach. > Our need (and major cause of annoyance) is that libraries developers > should provide their code in a rubygems-agnostic way, which means: This is unacceptable. Let me explain: RubyGems is a package manager, yes, but it is also a library, and a dependency manager. The difference between a package manager and a dependency manager is this: * A package manager manages out-of-process build time resource dependencies * A dependency manager manages a build, load, and runtime set of runtime dependencies For packages that exclusively use rubygems as a package manager, you would be fair to ask people to be agnostic, and indeed, in those cases it is easy. Packages that use rubygems as a library or as a dependency manager on the other hand, is a different story entirely. The call to Kernel#gem that occurs in binfiles for one example, will activate dependencies of the gem being loaded, and setup a runtime dependency tree making it possible (and implicitly configured) to load specific versions of other libraries that are needed, at runtime. Repackaging outside of rubygems removes features such as this, and also removes plugin features, platform configuration details (Gem.ruby, etc), and other extremely useful conveniences for the developer. One might claim that this is contrary to the unix philosophy of single purpose tools, and indeed, in some ways you would be correct, however, RubyGems is not a unix tool for stream processing, it's a platform tool, for helping people operate in a platform agnostic way. > - library distributed as a .tgz file in addition to a .gem file Due to the above reasons and many more, this is not possible for a large number of projects, and I don't think it is the right integration point for us anyway, as I believe I can provide better options than this. > - standard (setup.rb-like) file layout, so we can simply use setup.rb to > install the files You shouldn't be doing this, last time I checked setup.rb was GPLv2. Besides the obvious licensing issues, which I know matters to Debian, there are other significant issues with the approach of installing into site_ruby, which is another exact reason why RubyGems being used is so important: Imagine two libraries, both have a file with an event.rb file: cat lib1/lib/event.rb class Event; end cat lib2/lib/event.rb module Lib2::Event; end Now, lets say I install lib1, then lib2, in that order, using a setup.rb approach. In my runtime, I require lib1, and this is what happens: require 'event' # works class Blah; ....; end # all works Blah.new.go # => uninitialized constant Event (NameError) This is unavoidable using a setup.rb approach, and in fact, the above error is caused by this repackaging approach. It can also occur within rubygems itself, iff both libraries are activated at the same time, indeed, I patched the "aasm" gem for this violation some months ago. Like I say though, the problem is unavoidable with your approach, however, when used correctly by users, RubyGems provides a very powerful set of ways around these problems, by nature of being a runtime dependency manager that manages the $LOAD_PATH for the user from a well specified developer manifest (the gemspec). > - no "require 'rubygems'" in the code That's fine, however, that doesn't mean the project doesn't depend on RubGems, and more than that, it is expected to be part of the standard library as of Ruby 1.9. (Although this statement is also supposed to be unnecessary on 1.9 due to gem_prelude.rb). > - preferably no "require 'rubygems'" in the Rakefile or in the tests, to > make it possible/easier to run the test suite at package build time As above for the most part. > -- > | Lucas Nussbaum > | lucas at lucas-nussbaum.net http://www.lucas-nussbaum.net/ | > | jabber: lucas at nussbaum.fr GPG: 1024D/023B3F4F | From hgs at dmu.ac.uk Wed Mar 31 16:05:58 2010 From: hgs at dmu.ac.uk (Hugh Sasse) Date: Wed, 31 Mar 2010 21:05:58 +0100 (BST) Subject: [Rubygems-developers] Rubygems Packaging Enhancements and Designs In-Reply-To: <38F0B358-9035-4691-8D1A-DE82AB60AC0D@gmail.com> References: <38F0B358-9035-4691-8D1A-DE82AB60AC0D@gmail.com> Message-ID: On Wed, 31 Mar 2010, James Tucker wrote: > On 31 Mar 2010, at 10:02, Hugh Sasse wrote: [...] > > It could also be worth collecting a critical bibliography of > > published books that discuss how to use RubyGems, with a view > > to describing how current the information in them is. > > Mostly it needs to be clear (and documented) that for users, rubygems is well self-documented: > > gem help > gem help commands > That's clear and readily found. What isn't so clear is what is going on with require, gem versioning, and the deprecation of require_gem. Examples in some books will need to be changed. I think in the light of your response to my private email, I realise that I probably can't make the time commitment at the moment to contribute to this, which is principally why I have not explored the consequences of github package choices in sufficient depth. Hopefully things will be easier later. Hugh From jftucker at gmail.com Wed Mar 31 19:21:41 2010 From: jftucker at gmail.com (James Tucker) Date: Thu, 1 Apr 2010 00:21:41 +0100 Subject: [Rubygems-developers] Rubygems Packaging Enhancements and Designs In-Reply-To: References: <38F0B358-9035-4691-8D1A-DE82AB60AC0D@gmail.com> Message-ID: <87807826-397A-4FEB-B619-408C208B1B36@gmail.com> On 31 Mar 2010, at 21:05, Hugh Sasse wrote: > That's clear and readily found. What isn't so clear is what is going on > with require, gem versioning, and the deprecation of require_gem. Examples > in some books will need to be changed. I have done a first pass through the first book and fixed many of the broken items and loose markup, as well as added updates to reflect recent rubygems.org introduction and the gem push command. If you have more specific updates or have a moment to review the changes, further input would be welcome. > I think in the light of your response to my private email, I realise > that I probably can't make the time commitment at the moment to contribute > to this, which is principally why I have not explored the consequences of > github package choices in sufficient depth. Hopefully things will be > easier later. I hope so to, best of luck with the terms and conditions. From hgs at dmu.ac.uk Wed Mar 31 19:45:13 2010 From: hgs at dmu.ac.uk (Hugh Sasse) Date: Thu, 1 Apr 2010 00:45:13 +0100 (BST) Subject: [Rubygems-developers] Rubygems Packaging Enhancements and Designs In-Reply-To: <87807826-397A-4FEB-B619-408C208B1B36@gmail.com> References: <38F0B358-9035-4691-8D1A-DE82AB60AC0D@gmail.com> <87807826-397A-4FEB-B619-408C208B1B36@gmail.com> Message-ID: On Thu, 1 Apr 2010, James Tucker wrote: > > On 31 Mar 2010, at 21:05, Hugh Sasse wrote: > > That's clear and readily found. What isn't so clear is what is going on > > with require, gem versioning, and the deprecation of require_gem. Examples > > in some books will need to be changed. > > I have done a first pass through the first book and fixed many of the broken items and loose markup, as well as added updates to reflect recent rubygems.org introduction and the gem push command. I was still talking about examples from print books that are out there. Some will be made obsolete by more recent editions, we face the same upper bounds imposed by availability of people to do this, but I'm coming from the position that a continual criticism of Ruby has been the limits on its documentation. Provision of these corrections seems like it could be a good aspiration, even if we only make limited progress. > > If you have more specific updates or have a moment to review the changes, further input would be welcome. I'm clearly not looking in the right place, bowl me the URL and I'll see if I've anything useful to add. Hugh From luislavena at gmail.com Wed Mar 31 19:50:53 2010 From: luislavena at gmail.com (Luis Lavena) Date: Thu, 1 Apr 2010 01:50:53 +0200 Subject: [Rubygems-developers] Rubygems Packaging Enhancements and Designs In-Reply-To: References: <38F0B358-9035-4691-8D1A-DE82AB60AC0D@gmail.com> <87807826-397A-4FEB-B619-408C208B1B36@gmail.com> Message-ID: On Thu, Apr 1, 2010 at 1:45 AM, Hugh Sasse wrote: > On Thu, 1 Apr 2010, James Tucker wrote: > >> >> On 31 Mar 2010, at 21:05, Hugh Sasse wrote: >> > That's clear and readily found. ?What isn't so clear is what is going on >> > with require, gem versioning, and the deprecation of require_gem. Examples >> > in some books will need to be changed. >> >> I have done a first pass through the first book and fixed many of the broken items and loose markup, as well as added updates to reflect recent rubygems.org introduction and the gem push command. > > I was still talking about examples from print books that are out > there. ?Some will be made obsolete by more recent editions, we face > the same upper bounds imposed by availability of people to do this, > but I'm coming from the position that a continual criticism of Ruby > has been the limits on its documentation. ?Provision of these > corrections seems like it could be a good aspiration, even if we > only make limited progress. > Sorry to chime in, but is ilogical to assume that we can control an update every book out there. What you're suggesting is that backward compatibility should be maintained because "Programming Ruby", based on Ruby 1.6 is still out there in the hands of someone. It is true that RubyGems documentation site hasn't been updated, but if noone volunteers or provide feedback enough, that is not going to change. Developers are used to peek into the source. To step up as maintainer of a project you need to know what is made of and what are the tools to make it work. That is true for any project out there. -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exup?ry From hgs at dmu.ac.uk Wed Mar 31 20:15:14 2010 From: hgs at dmu.ac.uk (Hugh Sasse) Date: Thu, 1 Apr 2010 01:15:14 +0100 (BST) Subject: [Rubygems-developers] Rubygems Packaging Enhancements and Designs In-Reply-To: References: <38F0B358-9035-4691-8D1A-DE82AB60AC0D@gmail.com> <87807826-397A-4FEB-B619-408C208B1B36@gmail.com> Message-ID: On Thu, 1 Apr 2010, Hugh Sasse wrote: > On Thu, 1 Apr 2010, James Tucker wrote: > > > If you have more specific updates or have a moment to review the changes, further input would be welcome. > > I'm clearly not looking in the right place, bowl me the URL and I'll see > if I've anything useful to add. Ok, found it now: http://docs.rubygems.org/read/chapter/7#page27 That's good. I suppose the WikiWords will become proper links later. Only suggestion I have is for http://docs.rubygems.org/read/chapter/16#page74 (Pessamistic version control), and that is the flow of the text suggests that a couple of examples would fit nicely at the end: "~> 2.7.1.8" => ">= 2.7.1.8", "< 2.7.2" "~> 2.7.1" => ">= 2.7.1", "< 2.8" or something. I find examples help clarify rules even though they aren't always sufficient to allow the reader to deduce the rules without explanation. I think MetaFont used increasing precision of e as a version number. Hugh From jftucker at gmail.com Wed Mar 31 20:25:20 2010 From: jftucker at gmail.com (James Tucker) Date: Thu, 1 Apr 2010 01:25:20 +0100 Subject: [Rubygems-developers] Rubygems Packaging Enhancements and Designs In-Reply-To: References: <38F0B358-9035-4691-8D1A-DE82AB60AC0D@gmail.com> <87807826-397A-4FEB-B619-408C208B1B36@gmail.com> Message-ID: <2C35D659-CA3B-4F6C-AE9A-A76A81D32DC6@gmail.com> On 1 Apr 2010, at 00:45, Hugh Sasse wrote: > I was still talking about examples from print books that are out > there. Some will be made obsolete by more recent editions, we face > the same upper bounds imposed by availability of people to do this, > but I'm coming from the position that a continual criticism of Ruby > has been the limits on its documentation. Provision of these > corrections seems like it could be a good aspiration, even if we > only make limited progress. I agree wholeheartedly. The discussion always leads down the same path when I talk to people about it, rubyists seem to now have a culture of reading the code, and whilst that may breed better programmers in the end, it really hinders beginners. Updating our core documentation sources is a good start, and I've done a pass this evening as I say. Moving forward, we do need to encourage better documentation procedures, however, this requires some work on our infrastructure too, and ideally people need to stop blogging before doing documentation, or adding their blog posts to a doc/ directory or some suitably patchable place. >> If you have more specific updates or have a moment to review the changes, further input would be welcome. > > I'm clearly not looking in the right place, bowl me the URL and I'll see > if I've anything useful to add. My pass was through the user guide[1] primarily to look for examples that include deprecated code / apis, and update the markup to be slighly more presentable. I also added notes on `gem push` in the appropriate places. General consensus is that the command reference book[2] should be merged (where appropriate) into the docs inside 'gem help', and then removed or significantly cut down, to reduce maintenance load. [1] http://docs.rubygems.org/read/book/1 [2] http://docs.rubygems.org/read/book/2 From hgs at dmu.ac.uk Wed Mar 31 20:41:59 2010 From: hgs at dmu.ac.uk (Hugh Sasse) Date: Thu, 1 Apr 2010 01:41:59 +0100 (BST) Subject: [Rubygems-developers] Rubygems Packaging Enhancements and Designs In-Reply-To: References: <38F0B358-9035-4691-8D1A-DE82AB60AC0D@gmail.com> <87807826-397A-4FEB-B619-408C208B1B36@gmail.com> Message-ID: On Thu, 1 Apr 2010, Luis Lavena wrote: > On Thu, Apr 1, 2010 at 1:45 AM, Hugh Sasse wrote: > > On Thu, 1 Apr 2010, James Tucker wrote: > > > >> > >> On 31 Mar 2010, at 21:05, Hugh Sasse wrote: > >> > That's clear and readily found. ?What isn't so clear is what is going on > >> > with require, gem versioning, and the deprecation of require_gem. Examples > >> > in some books will need to be changed. > >> > >> I have done a first pass through the first book and fixed many of the broken items and loose markup, as well as added updates to reflect recent rubygems.org introduction and the gem push command. > > > > I was still talking about examples from print books that are out > > there. ?Some will be made obsolete by more recent editions, we face > > the same upper bounds imposed by availability of people to do this, > > but I'm coming from the position that a continual criticism of Ruby > > has been the limits on its documentation. ?Provision of these > > corrections seems like it could be a good aspiration, even if we > > only make limited progress. > > > > Sorry to chime in, but is ilogical to assume that we can control an > update every book out there. Agreed, we can't control or force updates, and some are far too old or obscure to merit much 3rd party effort.. > > What you're suggesting is that backward compatibility should be > maintained because "Programming Ruby", based on Ruby 1.6 is still out > there in the hands of someone. No, I'm suggesting that it would be useful to provide some information such that people can find this in relation to their book. (I'm certainly not suggesting we hold back development in order to meet constraints imposed by old texts.) I doubt much progress could be made in such an effort, but some might be possible, and it would help people get started. Clearly it is a low priority, but I'd only ask that it be kept in mind. I can state a case for this, but if everyone is so opposed that it is to be ruled out already, then I'll save the bandwidth. > > It is true that RubyGems documentation site hasn't been updated, but > if noone volunteers or provide feedback enough, that is not going to > change. Agreed. > > Developers are used to peek into the source. To step up as maintainer > of a project you need to know what is made of and what are the tools > to make it work. Yes, agreed. There are problems with this model, and the open source movement doesn't seem to address them.... > > That is true for any project out there. ...and the problems apply as broadly, in my experience. From ryand-ruby at zenspider.com Wed Mar 31 23:05:03 2010 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Wed, 31 Mar 2010 20:05:03 -0700 Subject: [Rubygems-developers] Rubygems Packaging Enhancements and Designs In-Reply-To: References: <38F0B358-9035-4691-8D1A-DE82AB60AC0D@gmail.com> <87807826-397A-4FEB-B619-408C208B1B36@gmail.com> Message-ID: <90CA14FE-2377-436B-9670-117FCAB4429A@zenspider.com> On Mar 31, 2010, at 17:15 , Hugh Sasse wrote: > That's good. I suppose the WikiWords will become proper links later. > Only suggestion I have is for > > http://docs.rubygems.org/read/chapter/16#page74 > > (Pessamistic version control), and that is the flow of the text > suggests that a couple of examples would fit nicely at the end: > > "~> 2.7.1.8" => ">= 2.7.1.8", "< 2.7.2" > "~> 2.7.1" => ">= 2.7.1", "< 2.8" I just modified the last paragraph to read: Notice that we only include 2 digits of the version. The operator will drop the final digit of a version, then increment the remaining final digit to get the upper limit version number. Therefore ?~> 2.2? is equivalent to: [?>= 2.2?, ?< 3.0?]. Had we said ?~> 2.2.0?, it would have been equivalent to: [?>= 2.2.0?, ?< 2.3.0?]. The last digit specifies the level of granularity of version control. (Remember, you can alway supply an explicit upper limit if the pessimistic operator is too limited for you). Edits welcome.