Identify replacement for Bintray for hosting releases

[jpd236]

Bintray is being sunset: https://jfrog.com/blog/into-the-sunset-bintray-jcenter-gocenter-and-chartcenter

Looks like we won't be able to upload new assets (e.g. deploy new production releases) as of 3/31. SNAPSHOT builds on oss.jfrog.org may be impacted by this, but I'm not certain; either way, without automatic Bintray promotion, there's not much benefit to hosting SNAPSHOT builds there.

SNAPSHOT steps:

• Create new repository in OSSRH (ticket)
• Migrate SNAPSHOT builds to OSSRH/Sonatype - see Publish SNAPSHOT builds to OSSRH instead of OJO. #397
• Update FAQ to point to new SNAPSHOT location for prerelease builds

Production release steps:

• Create new repository in Google Maven for production releases
• Create and announce new GPG key for future releases
• Write script to fetch a particular SNAPSHOT build corresponding with an RC, tweak versions, sign, and deploy to Maven Central + Google staging areas (equivalent to OJO's snapshotsToBintray API)
• Update internal deployment instructions to reflect new process, including running the script and promoting the releases from the staging areas on Maven Central + Google.
• Perform 1.2.0 release under new process to ensure new assets are available before JCenter turndown

[jameswald]

https://maven.google.com would be most convenient for developers

[joebowbeer]

GitHub provides a Maven package registry for this repo:

https://docs.github.com/en/packages/guides/configuring-apache-maven-for-use-with-github-packages

However, their Maven service doesn’t allow for unauthorized access right now. It is expected to be allowed in the future.

[Jawnnypoo]

Could you all publish to mavenCentral for now? Pretty sure Google has a profile on there and can look to other projects on how to publish

[mohsenoid]

Hey, as I also reported here
https://issuetracker.google.com/issues/179604852

I learned that com.google.android.libraries.places:places:2.4.0 is using com.android.volley:volley:1.1.1 and migrating to maven central will also fix the other libraries dependency issues.

[jpd236]

The sunset announcement has been updated - new versions will still be permitted through March 31st and downloads of existing binaries will be permitted through February 1st 2022, which buys us a bit more time.

At the moment, maven.google.com doesn't support SNAPSHOT hosting. We're exploring what it would take to add support for that internally, but in the likely event that it's not ready in time for the shutdown of new artifact uploads, we'll likely be using OSSRH (Sonatype). I'm working on establishing a repository there. This should enable fairly easy releases to Maven Central as well.

Given the demand for artifacts at maven.google.com, I plan to look into publishing our release versions there as well as a secondary mirror, if it wouldn't overcomplicate the setup.

We may need to sign the new release artifacts with a different GPG key than our current one, which is hosted on Bintray. Though I'm not sure if anyone is particularly dependent on the specific signing key, or what would happen if we mirrored our current release with a different key.

[jpd236]

SNAPSHOT builds are up and running at OSSRH, and the instructions to use them have been updated.

Next step here is to finalize the 1.2.0 release and push that to production mavenCentral and Google Maven.

[joshfeinberg-ah]

Would it be possible to upload the 1.1.1 release to mavenCentral and Google Maven as well? Since Places relies on it (and not sure if that library will get a corresponding update, it would be convenient to have that version available

[jpd236]

1.2.0-rc1 is now available on Google Maven and Maven Central. Please report any issues you find with the release or its deployment so we can resolve these before the final 1.2.0 release. It is signed with a new GPG key - from a look at other prominent Google projects, it appears to be the norm to use per-developer GPG keys rather than a unified project-level key, which implies they may change from release to release depending on who performs the release.

Regarding reuploading 1.1.1 - I have tried this, but both Google Maven and Maven Central have stricter requirements around POM metadata than Bintray did, and both are rejecting the existing 1.1.1 release as a result. We would need to issue a new release with a fixed POM and re-sign it, which would mean having two different "1.1.1" releases floating around, each with different POM files depending on which repository you happened to use. I admit I'm not 100% certain of the consequences of this, but it doesn't seem safe to me. One version code should correspond to one set of artifacts.

However, 1.2.0 should be compile-time and run-time backwards compatible with 1.1.1. I don't believe there are any circumstances in which an application that was built against 1.1.1 would fail when building or running against 1.2.0 instead; if any differences did exist, we'd give strong consideration to fixing them. In the common case that an app is dependent on a library which depends on Volley 1.1.1, the app could specify a dependency on 1.2.0 which should override that dependency and keep the application working. Similarly, there's not much benefit to a 1.1.2 release with just the POM fixes, since any app that upgrades to 1.1.2 should have no problem upgrading to 1.2.0 instead.

I think that's really the best we can hope to do here. My hope is that anyone specifically dependent on 1.1.1 can obtain it from Bintray over the next year, or that someone will create a read-only mirror of Bintray with a longer lifespan. I recommend following along here for a wider look at the problem.

Closing this out as the new release process is fully complete. We'll let the RC soak for a couple weeks or so, and if no further issues are reported, we can re-release as 1.2.0 final. Otherwise, we'll pick up fixes and build a new RC.

Thanks everyone for your feedback along the way!

[jpd236]

Perhaps ./gradlew dependencies will help you identify where the 1.1.1 dependency is coming from? You can see in https://docs.gradle.org/current/userguide/dependency_resolution.html#sub:resolution-strategy that Gradle's default strategy is to pick the highest requested version in the dependency graph, so either sometihng is using a custom resolution strategy, or your declaration isn't in the right place somehow.