You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by "James E. King III" <jk...@apache.org> on 2019/01/15 14:26:51 UTC
[VOTE] Next version number: 1.0
I'd like us to consider the next version number to be 1.0. The project is
mature enough, and some folks won't want a version 0.13. There are already
a number of accumulated breaking changes in interfaces of the C++,
JavaScript, and Java libraries. C++ especially, with the break away from
C++03 and boost as a link-time dependency has allowed us to change our code
significantly interface-wise. In js/node.js we not have correct 64-bit
integer handling. Of course, the wire protocol is still backwards
compatible. None of that has changed (not to my awareness). These changes
are documented in the top level CHANGES.md and in each language's README.md
file.
Let's vote.
[ ] +1 Next version number is 1.0.
[ ] 0 Don't care
[ ] -1 Next version number is 0.13.
Voting ends in 72 hours, Friday January 18 at 13:00 UTC.
Thanks,
Jim
Re: [VOTE] Next version number: 1.0
Posted by Xin Wang <xi...@gmail.com>.
+1 Next version number is 1.0.
Jens Geyer <je...@hotmail.com> 于2019年1月16日周三 上午6:33写道：
> [x] 0 Don't care
>
> -----Ursprüngliche Nachricht-----
> From: James E. King III
> Sent: Tuesday, January 15, 2019 3:26 PM
> To: dev@thrift.apache.org
> Subject: [VOTE] Next version number: 1.0
>
> I'd like us to consider the next version number to be 1.0. The project is
> mature enough, and some folks won't want a version 0.13. There are already
> a number of accumulated breaking changes in interfaces of the C++,
> JavaScript, and Java libraries. C++ especially, with the break away from
> C++03 and boost as a link-time dependency has allowed us to change our code
> significantly interface-wise. In js/node.js we not have correct 64-bit
> integer handling. Of course, the wire protocol is still backwards
> compatible. None of that has changed (not to my awareness). These changes
> are documented in the top level CHANGES.md and in each language's README.md
> file.
>
> Let's vote.
>
> [ ] +1 Next version number is 1.0.
> [ ] 0 Don't care
> [ ] -1 Next version number is 0.13.
>
> Voting ends in 72 hours, Friday January 18 at 13:00 UTC.
>
> Thanks,
>
> Jim
>
>
Re: [VOTE] Next version number: 1.0
Posted by Jens Geyer <je...@hotmail.com>.
[x] 0 Don't care
-----Ursprüngliche Nachricht-----
From: James E. King III
Sent: Tuesday, January 15, 2019 3:26 PM
To: dev@thrift.apache.org
Subject: [VOTE] Next version number: 1.0
I'd like us to consider the next version number to be 1.0. The project is
mature enough, and some folks won't want a version 0.13. There are already
a number of accumulated breaking changes in interfaces of the C++,
JavaScript, and Java libraries. C++ especially, with the break away from
C++03 and boost as a link-time dependency has allowed us to change our code
significantly interface-wise. In js/node.js we not have correct 64-bit
integer handling. Of course, the wire protocol is still backwards
compatible. None of that has changed (not to my awareness). These changes
are documented in the top level CHANGES.md and in each language's README.md
file.
Let's vote.
[ ] +1 Next version number is 1.0.
[ ] 0 Don't care
[ ] -1 Next version number is 0.13.
Voting ends in 72 hours, Friday January 18 at 13:00 UTC.
Thanks,
Jim
Re: [VOTE] Next version number: 1.0
Posted by "James E. King III" <jk...@apache.org>.
It sounds like a gating factor to switch to cmake then...
On Wed, Jan 16, 2019 at 10:40 AM Randy Abernethy <ra...@rx-m.com>
wrote:
> People have maturity expectations associated with a 1.0 release. So
> yes, my vote to do a release might be +1 while my vote for doing the
> same release as 1.0 might be -1 because I do not want to mislead the
> public.
>
> On Tue, Jan 15, 2019 at 7:32 PM James E. King III <jk...@apache.org>
> wrote:
> >
> > To do this we need to retire the autoconf build and make the cmake
> > environment as prolific as autoconf is, and be able to run cross tests on
> > Windows. That's a lot to ask, and we need to release at least twice in
> the
> > upcoming year, and three times in the next. No more once-per-year or
> more
> > releases, We have folks interested and engaged and we need to help them
> > contribute as much as possible.
> >
> > Votes aren't supposed to have conditions - do they? :)
> >
> > - Jim
> >
> > On Tue, Jan 15, 2019 at 9:48 AM Randy Abernethy <
> randy.abernethy@rx-m.com>
> > wrote:
> >
> > > I am very pro the 1.0 moniker on the next release. However I would put
> > > a few key criteria on it. Without these things I would be a strong -1.
> > > Here's my list:
> > >
> > > 1. A single build system and no trace of a duplicate/confusing second
> > > system (e.g. cmake everywhere)
> > > 2. No claims of support for anything that does not have a passing cross
> > > test
> > > 3. TBinaryProtocol support everywhere
> > > 4. A published specification for the RPC protocol
> > > 5. 0 or close to 0 open bug jira issues (there are over 300 right now)
> > >
> > > Each of these is tied to this statement at the top of the Thrift home
> page:
> > >
> > > "The Apache Thrift software framework, for scalable cross-language
> > > services development, combines a software stack with a code generation
> > > engine to build services that work efficiently and seamlessly between
> > > C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa,
> > > JavaScript, Node.js, Smalltalk, OCaml and Delphi and other languages."
> > >
> > > I would expect a 1.0 project to have few if any known bugs, to be
> > > fairly simple to build, to be specified and to do what is says (cross
> > > platform rpc), which must be born out in tests.
> > >
> > > A 1.0 release is a great goal.
> > >
> > > --Randy
> > >
> > > On Tue, Jan 15, 2019 at 6:27 AM James E. King III <jk...@apache.org>
> > > wrote:
> > > >
> > > > I'd like us to consider the next version number to be 1.0. The
> project
> > > is
> > > > mature enough, and some folks won't want a version 0.13. There are
> > > already
> > > > a number of accumulated breaking changes in interfaces of the C++,
> > > > JavaScript, and Java libraries. C++ especially, with the break away
> from
> > > > C++03 and boost as a link-time dependency has allowed us to change
> our
> > > code
> > > > significantly interface-wise. In js/node.js we not have correct
> 64-bit
> > > > integer handling. Of course, the wire protocol is still backwards
> > > > compatible. None of that has changed (not to my awareness). These
> > > changes
> > > > are documented in the top level CHANGES.md and in each language's
> > > README.md
> > > > file.
> > > >
> > > > Let's vote.
> > > >
> > > > [ ] +1 Next version number is 1.0.
> > > > [ ] 0 Don't care
> > > > [ ] -1 Next version number is 0.13.
> > > >
> > > > Voting ends in 72 hours, Friday January 18 at 13:00 UTC.
> > > >
> > > > Thanks,
> > > >
> > > > Jim
> > >
> > >
> > >
> > > --
> > >
> > > --
> > > Randy Abernethy
> > > Managing Partner
> > > RX-M, LLC
> > > randy.abernethy@rx-m.com
> > > o 415-800-2922
> > > c 415-624-6447
> > >
>
>
>
> --
>
> --
> Randy Abernethy
> Managing Partner
> RX-M, LLC
> randy.abernethy@rx-m.com
> o 415-800-2922
> c 415-624-6447
>
Re: [VOTE] Next version number: 1.0
Posted by Randy Abernethy <ra...@rx-m.com>.
People have maturity expectations associated with a 1.0 release. So
yes, my vote to do a release might be +1 while my vote for doing the
same release as 1.0 might be -1 because I do not want to mislead the
public.
On Tue, Jan 15, 2019 at 7:32 PM James E. King III <jk...@apache.org> wrote:
>
> To do this we need to retire the autoconf build and make the cmake
> environment as prolific as autoconf is, and be able to run cross tests on
> Windows. That's a lot to ask, and we need to release at least twice in the
> upcoming year, and three times in the next. No more once-per-year or more
> releases, We have folks interested and engaged and we need to help them
> contribute as much as possible.
>
> Votes aren't supposed to have conditions - do they? :)
>
> - Jim
>
> On Tue, Jan 15, 2019 at 9:48 AM Randy Abernethy <ra...@rx-m.com>
> wrote:
>
> > I am very pro the 1.0 moniker on the next release. However I would put
> > a few key criteria on it. Without these things I would be a strong -1.
> > Here's my list:
> >
> > 1. A single build system and no trace of a duplicate/confusing second
> > system (e.g. cmake everywhere)
> > 2. No claims of support for anything that does not have a passing cross
> > test
> > 3. TBinaryProtocol support everywhere
> > 4. A published specification for the RPC protocol
> > 5. 0 or close to 0 open bug jira issues (there are over 300 right now)
> >
> > Each of these is tied to this statement at the top of the Thrift home page:
> >
> > "The Apache Thrift software framework, for scalable cross-language
> > services development, combines a software stack with a code generation
> > engine to build services that work efficiently and seamlessly between
> > C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa,
> > JavaScript, Node.js, Smalltalk, OCaml and Delphi and other languages."
> >
> > I would expect a 1.0 project to have few if any known bugs, to be
> > fairly simple to build, to be specified and to do what is says (cross
> > platform rpc), which must be born out in tests.
> >
> > A 1.0 release is a great goal.
> >
> > --Randy
> >
> > On Tue, Jan 15, 2019 at 6:27 AM James E. King III <jk...@apache.org>
> > wrote:
> > >
> > > I'd like us to consider the next version number to be 1.0. The project
> > is
> > > mature enough, and some folks won't want a version 0.13. There are
> > already
> > > a number of accumulated breaking changes in interfaces of the C++,
> > > JavaScript, and Java libraries. C++ especially, with the break away from
> > > C++03 and boost as a link-time dependency has allowed us to change our
> > code
> > > significantly interface-wise. In js/node.js we not have correct 64-bit
> > > integer handling. Of course, the wire protocol is still backwards
> > > compatible. None of that has changed (not to my awareness). These
> > changes
> > > are documented in the top level CHANGES.md and in each language's
> > README.md
> > > file.
> > >
> > > Let's vote.
> > >
> > > [ ] +1 Next version number is 1.0.
> > > [ ] 0 Don't care
> > > [ ] -1 Next version number is 0.13.
> > >
> > > Voting ends in 72 hours, Friday January 18 at 13:00 UTC.
> > >
> > > Thanks,
> > >
> > > Jim
> >
> >
> >
> > --
> >
> > --
> > Randy Abernethy
> > Managing Partner
> > RX-M, LLC
> > randy.abernethy@rx-m.com
> > o 415-800-2922
> > c 415-624-6447
> >
--
--
Randy Abernethy
Managing Partner
RX-M, LLC
randy.abernethy@rx-m.com
o 415-800-2922
c 415-624-6447
Re: [VOTE] Next version number: 1.0
Posted by "James E. King III" <jk...@apache.org>.
To do this we need to retire the autoconf build and make the cmake
environment as prolific as autoconf is, and be able to run cross tests on
Windows. That's a lot to ask, and we need to release at least twice in the
upcoming year, and three times in the next. No more once-per-year or more
releases, We have folks interested and engaged and we need to help them
contribute as much as possible.
Votes aren't supposed to have conditions - do they? :)
- Jim
On Tue, Jan 15, 2019 at 9:48 AM Randy Abernethy <ra...@rx-m.com>
wrote:
> I am very pro the 1.0 moniker on the next release. However I would put
> a few key criteria on it. Without these things I would be a strong -1.
> Here's my list:
>
> 1. A single build system and no trace of a duplicate/confusing second
> system (e.g. cmake everywhere)
> 2. No claims of support for anything that does not have a passing cross
> test
> 3. TBinaryProtocol support everywhere
> 4. A published specification for the RPC protocol
> 5. 0 or close to 0 open bug jira issues (there are over 300 right now)
>
> Each of these is tied to this statement at the top of the Thrift home page:
>
> "The Apache Thrift software framework, for scalable cross-language
> services development, combines a software stack with a code generation
> engine to build services that work efficiently and seamlessly between
> C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa,
> JavaScript, Node.js, Smalltalk, OCaml and Delphi and other languages."
>
> I would expect a 1.0 project to have few if any known bugs, to be
> fairly simple to build, to be specified and to do what is says (cross
> platform rpc), which must be born out in tests.
>
> A 1.0 release is a great goal.
>
> --Randy
>
> On Tue, Jan 15, 2019 at 6:27 AM James E. King III <jk...@apache.org>
> wrote:
> >
> > I'd like us to consider the next version number to be 1.0. The project
> is
> > mature enough, and some folks won't want a version 0.13. There are
> already
> > a number of accumulated breaking changes in interfaces of the C++,
> > JavaScript, and Java libraries. C++ especially, with the break away from
> > C++03 and boost as a link-time dependency has allowed us to change our
> code
> > significantly interface-wise. In js/node.js we not have correct 64-bit
> > integer handling. Of course, the wire protocol is still backwards
> > compatible. None of that has changed (not to my awareness). These
> changes
> > are documented in the top level CHANGES.md and in each language's
> README.md
> > file.
> >
> > Let's vote.
> >
> > [ ] +1 Next version number is 1.0.
> > [ ] 0 Don't care
> > [ ] -1 Next version number is 0.13.
> >
> > Voting ends in 72 hours, Friday January 18 at 13:00 UTC.
> >
> > Thanks,
> >
> > Jim
>
>
>
> --
>
> --
> Randy Abernethy
> Managing Partner
> RX-M, LLC
> randy.abernethy@rx-m.com
> o 415-800-2922
> c 415-624-6447
>
Re: [VOTE] Next version number: 1.0
Posted by Randy Abernethy <ra...@rx-m.com>.
I am very pro the 1.0 moniker on the next release. However I would put
a few key criteria on it. Without these things I would be a strong -1.
Here's my list:
1. A single build system and no trace of a duplicate/confusing second
system (e.g. cmake everywhere)
2. No claims of support for anything that does not have a passing cross test
3. TBinaryProtocol support everywhere
4. A published specification for the RPC protocol
5. 0 or close to 0 open bug jira issues (there are over 300 right now)
Each of these is tied to this statement at the top of the Thrift home page:
"The Apache Thrift software framework, for scalable cross-language
services development, combines a software stack with a code generation
engine to build services that work efficiently and seamlessly between
C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa,
JavaScript, Node.js, Smalltalk, OCaml and Delphi and other languages."
I would expect a 1.0 project to have few if any known bugs, to be
fairly simple to build, to be specified and to do what is says (cross
platform rpc), which must be born out in tests.
A 1.0 release is a great goal.
--Randy
On Tue, Jan 15, 2019 at 6:27 AM James E. King III <jk...@apache.org> wrote:
>
> I'd like us to consider the next version number to be 1.0. The project is
> mature enough, and some folks won't want a version 0.13. There are already
> a number of accumulated breaking changes in interfaces of the C++,
> JavaScript, and Java libraries. C++ especially, with the break away from
> C++03 and boost as a link-time dependency has allowed us to change our code
> significantly interface-wise. In js/node.js we not have correct 64-bit
> integer handling. Of course, the wire protocol is still backwards
> compatible. None of that has changed (not to my awareness). These changes
> are documented in the top level CHANGES.md and in each language's README.md
> file.
>
> Let's vote.
>
> [ ] +1 Next version number is 1.0.
> [ ] 0 Don't care
> [ ] -1 Next version number is 0.13.
>
> Voting ends in 72 hours, Friday January 18 at 13:00 UTC.
>
> Thanks,
>
> Jim
--
--
Randy Abernethy
Managing Partner
RX-M, LLC
randy.abernethy@rx-m.com
o 415-800-2922
c 415-624-6447