Personaly I am not that interested in backwards compatibility. But I do
expect that the 2.0 API will stay frozen for a long time. The constant
changes are not good for this project.
Moreover, I do not think that there is an easy way to offer backwards
compatibility. I would suggest that you do not 'pollute' the facets
2.0directory with backwards compatibility code. Whoever wants to use
the old
API should use the older gem.
thank you,
George.
On 9/9/07, TRANS <transfire at gmail.com> wrote:
>> ---------- Forwarded message ----------
> From: Trans <transfire at gmail.com>
> Date: Sep 9, 2007 6:57 AM
> Subject: [Facets] Lay me out 2.0
> To: facets-universal at rubyforge.org>>> I'm just about ready to release version 2.0. I have only one last
> major decision to make, and it is an important one. So I thought it a
> good idea to put it out to the community.
>> As you know, Facets 1.8+ is laid out between facets/core/ and facets/
> more/ subdirectories. There is also a facet/ shortcut directory that
> simply contains files that redirect back to the first two. The idea
> being that the extension method libs were in core/, the other libs in
> more/, and facet/ was for convenience.
>> With Facets 2.0 there are two points that make things different:
>> 1) A goal of 2.0 was to make all the libs directly available via
> facets/, without the need for core/ or more/ or redirection.
>> 2) The extensions are no longer stored one-file-per-method, but are
> instead bundled with other closely related methods. However, Facets
> will still provide per-method requires via redirection files.
>> So those two points change things a bit. To take them into account,
> the current 2.0 layout looks like this:
>> lib/facets/ <-- all libs
> lib/facet/ <-- method redirects
>> Unfortunately this layout almost completely breaks backward-
> compatibility with 1.8.
>> Is there a remedy? I could offer backward compatibility if I did this
> instead:
>> lib/facets/core/ <-- method redirects
> lib/facets/more/ <-- additional libs
> lib/facets/xore/ <-- extension libs
>> Yes, the xore/ is a bit weird (do you have a better name?), but it
> keeps with the flow. With this layout I can use RubyGems' libpath
> specification parameter to add more/ and xore/ to the load path and
> achieve my first goal while remaining backward compatible with 1.8.
>> The problem though, is that _manual_ installs have no means of
> automatically adding to the load path. So those will need a special
> file that would either have to be loaded at the start of ones app or
> added to the RUBYOPT environment variable.
>> Is that extra hassle worth it?
>> And, with regard to require statements, how important is backward
> compatibility to you?
>> Thanks,
> T.
>> _______________________________________________
> facets-universal mailing list
>facets-universal at rubyforge.org>http://rubyforge.org/mailman/listinfo/facets-universal>>> --
> O trans
> ^^ transfire at gmail.com>> If there's one thing I learned from watching sitcoms it's this:
> whenever someone abruptly says "don't be silly", by all means be
> silly!
> _______________________________________________
> Nitro-general mailing list
>Nitro-general at rubyforge.org>http://rubyforge.org/mailman/listinfo/nitro-general>
--
http://www.me.grhttp://phidz.comhttp://blog.gmosx.comhttp://cull.grhttp://www.joy.grhttp://nitroproject.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070910/96d567a0/attachment.html