Hi Ahmet, On Fri, Aug 12, 2016 at 8:55 PM, Ahmet Altay <al...@google.com.invalid> wrote:
> Hi Sergio, > > Thank you for the integration PR. This will be very useful. As an immediate > benefit Python SDK will have precommit coverage through Jenkins. There was > already existing coverage with Travis, nevertheless this will give us > additional testing. It is also an important step towards maturing the > python- > sdk branch to be merged into the master branch. My opinion is to get this > bit > in and benefit from it now. > > Related to versioning bit. I believe Silviu wanted to get the Maven > integration first. It is now a good time to have this discussion. Sure, and I agreed on that, step by step is always better. I just wanted to bring the discussion to dev@, where I expect people has a broader opinion where to go in the mid-long term. > There > are two components to this discussion: > > (1) Reading the version information from the pom.xml. This should happen > regardless of what versioning strategy we choose. We can continue this > discussion on how to implement that in BEAM-547. > > (2) What version to use for Python SDK? This is a better forum to answer > this question. > > As a context, there was an earlier community discussion on this [1][2]: > > > Finally, we propose the standard approach where the entire source code > lives > > in each branch and is released concurrently. We’d like to avoid the case > > where individual modules are released on different cadences and are being > > maintained in different branches of the main repository. This is > beneficial > > because we don’t need to worry as much about versioning some of the > surfaces > > between components. However, for components that have a stable surface or > > across languages, we can relax this, as appropriate. Additionally, this > can > > be relaxed for hotfixes and different SDK languages. > > Based on the above quote by default we should use the same version, however > it > is also possible to relax that requirement for a different SDK. > Interesting... I propose that Python SDK to be versioned differently for two reasons: > > (1) Python SDK does not have all the features yet and it is likely that it > will > play catch up for a while. During this time it would be confusing to the > users. A user might assume that a released Python SDK with version X to > have > all the features that are available in Java SDK version X. > (2) In the future, it is possible that different user communities might > embrace > different SDKs. Having different versions would give the flexibility to the > SDK > developers to prioritize feature request differently and potentially have > non-synchronized release schedules. > I agree, SDKs has a different lifecycle that APIs, so that need to be covered by the versioning strategy. Not sure if it has been discussed. But commonly to version APIs and SDKs sometimes people uses the following schema: - version X.Y identifies the API - version X.Y.Z identified the SDK compatible with API X.Y Anyway, as we did with the code PR, I'd prefer to keep the versioning for later discussion. Firstly I'd focus on agreeing, or not, in using the Maven build also for the Python SDK. Cheers, -- Sergio Fernández Partner Technology Manager Redlink GmbH m: +43 6602747925 e: sergio.fernan...@redlink.co w: http://redlink.co
