How close is gRPC to a release candidate?

[jdov...@gmail.com]

I know that different parts of gRPC are more mature than others but in general how far are we from a formal release candidate?

TIA

[Louis Ryan]

Pretty close. Take a look at the GA milestones on the repos to get an idea

https://github.com/grpc/grpc/milestones

https://github.com/grpc/grpc-java/milestones

On Tue, Jul 26, 2016 at 8:56 AM, <jdov...@gmail.com> wrote:

I know that different parts of gRPC are more mature than others but in general how far are we from a formal release candidate?

TIA

--
You received this message because you are subscribed to the Google Groups "grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+u...@googlegroups.com.
To post to this group, send email to grp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/d5d76009-e376-4fb3-8248-63907ecc88a3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Nathaniel Manista]

On Tue, Jul 26, 2016 at 8:56 AM, <jdov...@gmail.com> wrote:

I know that different parts of gRPC are more mature than others but in general how far are we from a formal release candidate?

If you're working in Python, the current grpcio package is 1.0.0rc1 with the "rc" indicating that it is a release candidate.

-Nathaniel

[jdov...@gmail.com]

Thanks for the replies.

Initially my main uses will be in Java, Node, and C#.

[Paul Grosu]

I understand the need, but rushing things with a complex programming project such as this does not always translate into quality.  With this project I would prefer Google to take their time to do it right.  The gRPC team are doing fantastic service, but already they feel way too stretched out in terms of resources, and that can be clearly seen from some of the reverted pull requests 

Lately PRs have been flying off the shelf more frequently than usual - assuming in preparation for the GA release, which is listed as 2 months behind schedule - and there are still 111 PRs with 554 open issues in the queue on Github.  Once things stabilize, then maybe we can revisit something that would be testable as a release candidate.   We don't even have the step-wise design specifications for the project - including target features for release - and the project's guide for the team seems to be just a spreadsheet.

This approach has always proven true in all the places that I worked.

Paul

[Louis Ryan]

Paul,

On Wed, Jul 27, 2016 at 10:00 AM, Paul Grosu <pgr...@gmail.com> wrote:

I understand the need, but rushing things with a complex programming project such as this does not always translate into quality.  With this project I would prefer Google to take their time to do it right.  The gRPC team are doing fantastic service, but already they feel way too stretched out in terms of resources, and that can be clearly seen from some of the reverted pull requests 

Lately PRs have been flying off the shelf more frequently than usual - assuming in preparation for the GA release, which is listed as 2 months behind schedule - and there are still 111 PRs with 554 open issues in the queue on Github.  Once things stabilize, then maybe we can revisit something that would be testable as a release candidate.   We don't even have the step-wise design specifications for the project - including target features for release - and the project's guide for the team seems to be just a spreadsheet.

In the interests of efficiency we have tried to use GitHub milestones to communicate what would be in a specific release. Take a look at some of the 1.1 milestones for features that have been pushed to 'next' 

Going forward we'll probably assess whether the use of milestones was an effective form of communication, it's certainly been a challenge to lean on GitHub while communicating progress on features that span several projects.

This is definitely an area we'll try to do better on going forward

This approach has always proven true in all the places that I worked.

Paul

On Wednesday, July 27, 2016 at 10:11:41 AM UTC-4, jdov...@gmail.com wrote:

Thanks for the replies.

Initially my main uses will be in Java, Node, and C#.

On Tuesday, July 26, 2016 at 8:32:35 PM UTC-7, Nathaniel Manista wrote:

On Tue, Jul 26, 2016 at 8:56 AM, <jdov...@gmail.com> wrote:

I know that different parts of gRPC are more mature than others but in general how far are we from a formal release candidate?

If you're working in Python, the current grpcio package is 1.0.0rc1 with the "rc" indicating that it is a release candidate.

-Nathaniel

--

You received this message because you are subscribed to the Google Groups "grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+u...@googlegroups.com.
To post to this group, send email to grp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/bee7c8d3-8718-46cb-9107-b8f5a67b6a23%40googlegroups.com.

[Paul Grosu]

Hi Louis,

Thank you for the milestones information, and am comfortable to hear that more options are being evaluated for engaging users with the progress.  Some of the milestones make sense, but some feel like tickets on issues, and the Jenkins ones I do not believe fall under user features.

Since gRPC is a multi-project endeavour, the releases should usually progress in step, with the assumption that features and API methods are the same in all languages.  For instance, the MetadataCredentialsPlugin seems to be unique to C++.  Imagine if Protocol Buffers varied between languages.  Since the motivation was to rework Stubby, then a new clean framework is assumed to be the end-goal.  Thus any piece of code of this framework would stem from a behavior-driven development (BDD) specification plan, that matches the usage requirements, where the flow of information is detailed.  To have a purpose for each piece of code and thus make it intuitively ubiquitous among languages, a test-driven development (TDD) process follows to provide minimum satisfiability requirements of functionality. Each test would have a documented purpose, so as to link them accordingly and allow for proper class/function contract definitions.  This is all a mechanical process - including predictability of all pull-requests - and ensures compatibility of implementation among languages, which naturally brings end-users great joy when working with it.  We unfortunately still do not seem to have any project plan.

To accomplish consistency, the simplest approach would entail building a feature matrix to connect implementations together, and then to use as roadmaps for different versions.  Such roadmaps would become project plan with dated milestones.  The features would reside on the right-hand side, with languages at the top - with one per column.  Below is a link to an example:

   http://blog.cloudera.com/wp-content/uploads/2013/01/features.png

An example of released features, the Google Dataflow approach looks very appealing, as noted by the following link:

   https://cloud.google.com/dataflow/release-notes/java

Lately the gRPC-Java releases reflect more like features:

   https://github.com/grpc/grpc-java/releases/

I propose that more frequent engagement with the user community through organized gathering of features, and voting of highly requested features would go along way to include key sought-after features.  A project plan and detailed documentation on the shared core C library implementation, would allow other languages to be plugged in as surface APIs.  A centrally located, periodically updated project plan would allow users to not only engage with, but plan for.  Additional documentation that allows for users of different levels to have a welcome experience in using the API will also go a long way.  I am happy to see - based on the last gRPC User Forum - that my recommendation to use ReadTheDocs was utilized to document at least the Python API.

Let's keep working together to help each other out, as it will go a long way to inspire even more user engagement and the continued growth of a fruitful community.  By facilitating more adoption, one never knows where a great idea might reside just like how SPDY, HTTP/2, and QUIC motivated this project.

Hope these are all points of agreement, and I welcome elaborative discussions on any of them.

Thank you,
Paul