You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by Anthony Molinaro <an...@alumni.caltech.edu> on 2012/02/22 08:31:58 UTC
Versioning of erlang
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
--
------------------------------------------------------------------------
Anthony Molinaro <an...@alumni.caltech.edu>
Re: Versioning of erlang
Posted by Anthony Molinaro <an...@alumni.caltech.edu>.
Hi Jake,
Okay, so I made this change here
(https://issues.apache.org/jira/browse/THRIFT-1520).
Hudson failed, but that was because I forgot to remove the entry
from configure.ac which I did, so I assume next Hudson run will
work (not sure how often it runs).
There's really no central place for erlang packages, rebar is a build
tool which will pull the source directly and build it locally in an
erlang project. I tested that and it works great (well except for
the unit tests which currently require generated code, I think I need
to figure out library unit tests which will work sans generation, and
have the generated tests done somewhere else. Luckily the work around
is the skip the unit tests for dependencies which rebar supports).
I'll keep an eye out to see that Hudson eventually recovers.
As for changes when we have a version change, just edit
lib/erl/src/thrift.app.src
and change the line that looks like
{vsn,"0.9.0-dev"}
Thanks,
-Anthony
On Wed, Feb 22, 2012 at 01:15:09PM -0600, Jake Farrell wrote:
> 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.
>
--
------------------------------------------------------------------------
Anthony Molinaro <an...@alumni.caltech.edu>
Re: Versioning of erlang
Posted by Jake Farrell <jf...@apache.org>.
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.
Re: Versioning of erlang
Posted by Dmitriy Kargapolov <dm...@gmail.com>.
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.
Re: Versioning of erlang
Posted by Joel Meyer <jo...@gmail.com>.
On Wed, Feb 22, 2012 at 9:04 AM, Anthony Molinaro <
anthonym@alumni.caltech.edu> 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?
>
I started a thread on the rebar mailing list to ask advice on how best to
make erl thrift play well with rebar, since my efforts didn't work. The
predominant advice was to fork the part of thrift I care about, which I'd
prefer not to do.
As Anthony mentioned, the erl library is already 99% of the way there, the
package version macro is the last thing getting in the way. Anthony has
proposed a way of making it 100% compatible, which I and the rest of the
thrift/erl community would really benefit from.
> 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.
>
Agreed, I'd love to see the official thrift erl repo be embeddable via
rebar. Then we could encourage people to move away from forking and
modifying.
That's my perspective as an end-user of the project, Anthony has a better
sense of what's best from the overall project perspective.
Thanks,
Joel
> 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 Molinaro <an...@alumni.caltech.edu>
>
Re: Versioning of erlang
Posted by Anthony Molinaro <an...@alumni.caltech.edu>.
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 Molinaro <an...@alumni.caltech.edu>
Re: Versioning of erlang
Posted by Dmitriy Kargapolov <dm...@gmail.com>.
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?