Anthony
i'm good with that if it makes distributing the lib easier, just let me know
where the version number needs to be updated so I can update it when making a
release. Is there a standard place for erlang packages to be distributed from
that I can go apply at so I could push the erl client package out with each
release?
-Jake
On Feb 22, 2012, at 11:18 AM, Dmitriy Kargapolov wrote:
> On 02/22/2012 12:04 PM, Anthony Molinaro wrote:
>> On Wed, Feb 22, 2012 at 07:55:05AM -0500, Dmitriy Kargapolov wrote:
>>> On 02/22/2012 02:31 AM, Anthony Molinaro wrote:
>>>> Hi,
>>>>
>>>> So I was noticing that many of the other bindings have the thrift
>>>> version embedded in their libraries. Turns out this would help with
>>>> the usability of the erlang library as well, does anyone have an
>>>> issue with me changing things to work in this way?
>>>>
>>>> Basically, I'd get rid of lib/src/thrift.app.src.in, and instead
>>>> have a lib/src/thrift.app.src which has the version number in it.
>>>>
>>>> This file would need to be updated anytime the version is changed.
>>>>
>>>> Sound okay?
>>>>
>>>> -Anthony
>>>>
>>> Once you run ./configure the correct version should be written instead
>>> of "@PACKAGE_VERSION@" macro in the resulting lib/erl/src/thrift.app.src
>>> anyway. What is the problem with this traditional approach?
>> Yes, I know I set it up that way, however, that doesn't play well with
>> rebar dependency management which is how most people want to build
>> their erlang these days. In that case they'd like to do something like
>>
>> {deps, [ { thrift, "0.9.0", {svn,
>> "https://svn.apache.org/repos/asf/thrift/trunk/lib/erl/";, []}}]}.
>>
>> in their rebar.config and have it work, the only thing preventing this
>> now is the fact that I took the route of substituting @PACKAGE_VERSION@.
>>
>> However, looking through many of the other bindings I seem to be the
>> only one who took that approach, and its lead to many in the erlang
>> community forking off just the lib/erl directory which seems bad IMHO.
>>
>> Since the other bindings seem to hardcode a version, it looks like
>> Jake updates them with releases, and if the erlang binding had a
>> hardcoded version it would allow people to build it independendently
>> via a rebar deps inclusion, I feel it would be the best course of
>> action to hardcode the version for the erlang library as well.
>>
>> -Anthony
>>
> Anthony,
> Thank you for detailed explanation. I would not follow community in what
> is not perfect per my opinion, but I understand your position. Actually,
> there are some much more important things to work on, performance is the
> fist one.
> Thanks again.
