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.aberne...@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.aberne...@rx-m.com
> o 415-800-2922
> c 415-624-6447
>

Reply via email to