Agree on the low bar. We should just make them all 0.x releases to send the right message (don't use, and no compatibility) and not worry as much about bad releases, which we would never actually depend on in the project.
QQ: What does the new -P flag do? I was also hoping to eliminate the redundant -PisRelease flag, especially for vendored deps that should really be straight line. Kenn On Wed, Nov 14, 2018 at 12:38 PM Lukasz Cwik <lc...@google.com> wrote: > Its a small hassle but could be checked in with some changes, my example > commit was so that people could try it out as is. > > I'll work towards getting it checked in and then start a release for gRPC > and guava. > > On Wed, Nov 14, 2018 at 11:45 AM Scott Wegner <sc...@apache.org> wrote: > >> Thanks for pushing this forward Luke. >> >> My understanding is that these vendored grpc artifacts will only be >> consumed directly by Beam internal components (as opposed to Beam user >> projects). So there should be a fairly low bar for publishing them. But >> perhaps we should have some short checklist for releasing them for >> consistency. >> >> One item I would suggest for such a checklist would be to publish >> artifacts from checked-in apache/beam sources and then tag the release >> commit. Is it possible to get your changes merged in first, or is there a >> chicken-and-egg problem that artifacts need to be published and available >> for consumption? >> >> On Wed, Nov 14, 2018 at 10:51 AM Lukasz Cwik <lc...@google.com> wrote: >> >>> Note, I could also release the vendored version of guava 20 in >>> preparation for us to start consuming it. Any concerns? >>> >>> On Tue, Nov 13, 2018 at 3:59 PM Lukasz Cwik <lc...@google.com> wrote: >>> >>>> I have made some incremental progress on this and wanted to release our >>>> first vendored dependency of gRPC 1.13.1 since I was able to fix a good >>>> number of the import/code completion errors that Intellij was experiencing. >>>> I have published an example of what the jar/pom looks like in the Apache >>>> Staging repo: >>>> >>>> https://repository.apache.org/content/groups/snapshots/org/apache/beam/beam-vendor-grpc-1_13_1/ >>>> >>>> You can also checkout[1] and from a clean workspace run: >>>> ./gradlew :beam-vendor-grpc-1_13_1:publishToMavenLocal -PisRelease >>>> -PvendoredDependenciesOnly >>>> which will build a vendored version of gRPC that is published to your >>>> local maven repository. All the projects that depended on the gradle >>>> beam-vendor-grpc-1_13_1 project are now pointing at the Maven artifact >>>> org.apache.beam:beam-vendor-grpc-1_13_1:0.1 >>>> >>>> I was planning to follow the Apache Beam release process but only for >>>> this specific artifact and start a vote thread if there aren't any >>>> concerns. >>>> >>>> 1: >>>> https://github.com/lukecwik/incubator-beam/commit/4b1b7b40ef316559f81c42dfdd44da988db201e9 >>>> >>>> >>>> On Thu, Oct 25, 2018 at 10:59 AM Lukasz Cwik <lc...@google.com> wrote: >>>> >>>>> Thats a good point Thomas, hadn't considered the lib/ case. I also am >>>>> recommending what Thomas is suggesting as well. >>>>> >>>>> On Thu, Oct 25, 2018 at 10:52 AM Maximilian Michels <m...@apache.org> >>>>> wrote: >>>>> >>>>>> On 25.10.18 19:23, Lukasz Cwik wrote: >>>>>> > >>>>>> > >>>>>> > On Thu, Oct 25, 2018 at 9:59 AM Maximilian Michels <m...@apache.org >>>>>> > <mailto:m...@apache.org>> wrote: >>>>>> > >>>>>> > Question: How would a user end up with the same shaded >>>>>> dependency >>>>>> > twice? >>>>>> > The shaded dependencies are transitive dependencies of Beam and >>>>>> thus, >>>>>> > this shouldn't happen. Is this a safe-guard when running >>>>>> different >>>>>> > versions of Beam in the same JVM? >>>>>> > >>>>>> > >>>>>> > What I was referring to was that they aren't exactly the same >>>>>> dependency >>>>>> > but slightly different versions of the same dependency. Since we >>>>>> are >>>>>> > planning to vendor each dependency and its transitive dependencies >>>>>> as >>>>>> > part of the same jar, we can have vendor-A that contains shaded >>>>>> > transitive-C 1.0 and vendor-B that contains transitive-C 2.0 both >>>>>> with >>>>>> > different package prefixes. It can be that transitive-C 1.0 and >>>>>> > transitive-C 2.0 can't be on the same classpath because they can't >>>>>> be >>>>>> > perfectly shaded due to JNI, java reflection, magical property >>>>>> > files/strings, ... >>>>>> > >>>>>> >>>>>> Ah yes. Get it. Thanks! >>>>>> >>>>> >> >> -- >> >> >> >> >> Got feedback? tinyurl.com/swegner-feedback >> >
