> > We do have it in the tarball root for the real release OK, I see it now in the tarball. Where is the script or code that loads the data into git.version ?
If they stay separate... Yes, I understand. Once we graduate (PPMC -> PMC), isn't it just the PMC that votes on a release? On Wed, Jul 31, 2019 at 7:46 PM Gian Merlino <[email protected]> wrote: > > I gather you decided not to have a git.version file at the root and you > > added that info into the jar manifests, so where do you have that > > information for the tar.gz assemblies? > > We do have it in the tarball root for the real release -- the source > tarball (ASF policy considers source releases as the sole official > release). For the binary convenience artifacts, we don't include it at the > root, but the jars have the info if people go digging. > > > Even the Java-only components have vastly different dependencies and > > version cycles and don't necessarily need to be released at the same time > > the core-java component is released. So far, we don't have releases that > > span multiple components. For example, the core-java library may be > > several versions ahead of the hive or pig components. > > Sure, that makes sense. I would still consider aligning their release > processes though. If they stay separate, each component release would need > its own release manager, its own voting cycle, its own publish and > announcement process, etc, and that can be a lot of administrative > overhead. > > On Wed, Jul 31, 2019 at 7:07 PM leerho <[email protected]> wrote: > > > Gian, > > Thanks! > > > > > > > https://github.com/apache/incubator-druid/pull/6482. > > > > > > The discussion about the traceability of the GA back to the final RC is > > interesting. > > I gather you decided not to have a git.version file at the root and you > > added that info into the jar manifests, so where do you have that > > information for the tar.gz assemblies? > > > > Also, it is more work upfront, but you might find that in the long run, > you > > > enjoy switching the project to a single repo with a multi-module Maven > > > build. We do this in Druid and it works quite well. It makes it way > > easier > > > to do patches and releases that span multiple modules. > > > > > > The DataSketches library is not like a single product with components > that > > are released together. Some of our "components" have different > life-cycles > > and versioning. Also, we have C++ / Python repositories that don't fit > > well with Maven, which is all about Java. > > > > Even the Java-only components have vastly different dependencies and > > version cycles and don't necessarily need to be released at the same time > > the core-java component is released. So far, we don't have releases that > > span multiple components. For example, the core-java library may be > > several versions ahead of the hive or pig components. > > > > Definitely doing as much as possible in the build system (whether Maven > or > > > Gradle) is a good thing, IMO, since they tend to reward living in their > > > worlds. Also the more verifications you can push into the build tool, > the > > > better. > > > > > > I agree. > > > > GPG ? > > > > > > You are correct. The .asc signature is generated with GPG. > > > > > > > > > > On Tue, Jul 30, 2019 at 5:22 PM Gian Merlino <[email protected]> wrote: > > > > > Hey Lee, > > > > > > You might find this PR useful, it is where we Apache-fied the Druid > POM: > > > https://github.com/apache/incubator-druid/pull/6482. It helps > highlight > > > the > > > specific areas that are relevant to Apache-fying a build. > > > > > > Also, it is more work upfront, but you might find that in the long run, > > you > > > enjoy switching the project to a single repo with a multi-module Maven > > > build. We do this in Druid and it works quite well. It makes it way > > easier > > > to do patches and releases that span multiple modules. > > > > > > > So it seems that eventually, either we need to go whole hog having > > Maven > > > do > > > > everything, which seems overly complicated, or consider moving to > > Gradle > > > > (which I am not familiar with either, but it seems lots of teams are > > > moving > > > > that way). > > > > > > Definitely doing as much as possible in the build system (whether Maven > > or > > > Gradle) is a good thing, IMO, since they tend to reward living in their > > > worlds. Also the more verifications you can push into the build tool, > the > > > better. > > > > > > In Druid we have also been considering moving to Gradle: > > > https://github.com/apache/incubator-druid/issues/7866. However we are > > > still > > > using Maven for now and may be for some time to come, since it seems > the > > > benefits of switching to Gradle are definitely noticeable, but not > huge. > > > > > > > - It doesn't appear that the Nexus artifacts require a GPG signature > > only > > > > the DIST assembly requires GPG, which the script is handling. So why > > do > > > we > > > > need the gpg-plugin? > > > > > > IIRC it's because Sonatype's Central Repository (where the Maven-ready > > > artifacts ultimately end up) requires GPG signatures. > > > > > > > - It is not clear to me when a profile should be used (e.g., for > > deploy) > > > vs > > > > using the deploy process as part of the pom main build lifecycle. > > > > > > I've found profiles to be most useful when you want something like "mvn > > > package" to do different things based on a profile. e.g. having a > profile > > > to apply strict checks that takes extra time, having a profile to build > > > extra assemblies, etc. > > > > > >
