Skip to content

Java: support multiple versions per release #74

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 16 commits into from
Oct 9, 2018

Conversation

chingor13
Copy link
Contributor

@chingor13 chingor13 commented Oct 5, 2018

Java publishes packages together and different artifacts are versioned independently. We already have precedent in google-cloud-java to manage all versions in a versions.txt file at the root directory and to be able to annotate places to replace throughout the README.md and pom.xml files.

This PR replaces the current utilites/bump_versions.py and utilities/replace_versions.py scripts in google-cloud-java so they can be used with other repositories like gax-java.

The workflow is now:

  1. What type of release? (MINOR|patch|snapshot)
  2. Bump versions.txt? (Y/n)
  3. Update versions in pom.xml files? (Y/n)
  4. Edit release notes
  5. Create release branch? (Y/n)
  6. Create PR? (Y/n)

See googleapis/google-cloud-java#3777

This should make releasetool work for all of google-cloud-java, gax-java, google-auth-library-java, google-api-java-client, google-http-java-client, google-oauth-java-client.

@googlebot googlebot added the cla: yes This human has signed the Contributor License Agreement. label Oct 5, 2018
@chingor13
Copy link
Contributor Author

@theacodes @busunkim96 As I'm not a pythonista yet, should I break the internal classes in here into separate files?

@garrettjonesgoogle
Copy link
Member

What would the usage look like in gax-java?

@chingor13
Copy link
Contributor Author

I haven't looked into the gradle release process yet.

@garrettjonesgoogle
Copy link
Member

I don't think it needs to be built into the gradle release process yet; the question was more about how the direct commands would look.

@chingor13
Copy link
Contributor Author

@garrettjonesgoogle I meant looking into how gradle handles release and snapshot versioning. The releasetool workflow should be identical.

@garrettjonesgoogle
Copy link
Member

@chingor13 Ok. So what commands would I run manually to invoke the bump & replace-versions logic?

@chingor13
Copy link
Contributor Author

If you want to separate the steps, you can do so by replying no to selective prompts. Both scenarios would start with releasetool start.

If you want to just bump, you can say yes to updating versions.txt, and no to updating the pom files.

If you want to just replace the versions, you can say no to updating versions.txt and yes to updating the pom files.

@chingor13 chingor13 changed the title WIP: Java: support multiple versions per release Java: support multiple versions per release Oct 8, 2018
Copy link
Member

@garrettjonesgoogle garrettjonesgoogle left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm cool with this

@chingor13
Copy link
Contributor Author

This is ready to go whenever.

@JustinBeckwith JustinBeckwith merged commit 7a56168 into googleapis:master Oct 9, 2018
@chingor13 chingor13 deleted the java-multiple-versions branch January 7, 2019 18:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cla: yes This human has signed the Contributor License Agreement.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants