[Rubygems-developers] Another plug for Simon's patch

Gavin Sinclair gsinclair at soyabean.com.au
Fri Apr 2 08:40:04 EST 2004


On Friday, April 2, 2004, 7:39:30 AM, Mauricio wrote:

>> I think most developers would agree that a standard version numbering
>> method would be desirable (even if you couldn't get them to agree what the
>> method should be).
>> 
>> Just like naming conventions ("read_http_stream" vs. readHttpStream), it
>> helps when developers follow the community's defacto standard, but its not
>> required. Couldn't we do the same here -- if you follow the "standard"
>> versioning scheme, your stuff will play better with RubyGems, but its not
>> required that you do so.

> Of course devels. won't (and couldn't anyway) be forced to follow these
> rules, but rubygems could issue a strong recommendation -- I don't think
> trying to drive adoption of a good practice can be bad.

> Regarding the practical measures, in another msg I proposed that
> * at least equal importance be attached to the versioning policy as to other
>   technicalities in rubygems' documentation (I'd put it *before*
>   'Creating the Gem Specification' in the 'RubyGems Developer Documentation
>   Area').

It's a different area.  I'd say create a document that outlines a
sensible policy that we'd like all gems to adhere to, and explain why,
and then link to that document from other places.  It's not something
that needs to be rammed down people's throats, inline, at every step.

> * the rubygems team make sure that the versioning policy is explained in the
>   2nd edition of the Pickaxe (this makes sense since rubygems will
>   change for sure, but the versioning policy ought to remain stable).

Yep, good idea.

> * in general, that the versioning policy be considered a fundamental part of
>   rubygems and that all needed measures be adopted to ensure that no 'gem
>   packager' will break the system unintentionally. (edited)

I'm not sure about this.  Actually policing it seems a bit
heavy-handed for what it, essentially, an enabling technology.  I'd
like to know what you think are "all needed measures".

Making a policy a "fundamental part" of a technology seems misguided
to me, like builing anti-spam mechanisms into POP3.

Cheers,
Gavin




More information about the Rubygems-developers mailing list