Skip to content
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

Have the ability to insert major, minor and revision constants into source files. #435

Closed
dpcollins-google opened this issue May 18, 2020 · 4 comments · Fixed by #1157
Closed
Assignees
Labels
type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design.

Comments

@dpcollins-google
Copy link

It should be possible to access the version of a library in code. Currently this is (afaik) only possible in java with https://googleapis.dev/java/gax/latest/com/google/api/gax/core/GaxProperties.html#getLibraryVersion-java.lang.Class-, which reaches into the maven metadata to do so.

It would be useful to be able to paste MAJOR_VERSION = x MINOR_VERSION = y, REVISION = z constants in each language, or even just the numbers representing them by regex substitution into source files upon release.

@yoshi-automation yoshi-automation added triage me I really want to be triaged. 🚨 This issue needs some love. labels May 19, 2020
@bcoe bcoe added the type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design. label May 24, 2020
@bcoe
Copy link
Contributor

bcoe commented May 24, 2020

@dpcollins-google the way folks tend to do this in the Node.js community is to require('package.json'), as Node.js allows you to require JSON, and the version is in the package.json file.

I'd would be curious to know the best way to approach this for Python, happy to add language specific stuff like this.

@yoshi-automation yoshi-automation removed 🚨 This issue needs some love. triage me I really want to be triaged. labels May 24, 2020
@chingor13
Copy link
Contributor

We now support an extraFiles option which, for Java, will do it's standard version replacements (via those special comment annotations) in arbitrary files configured. Here's an example in the Bigtable repo: https://github.com/googleapis/java-bigtable/pull/715/files#diff-35de1d9d9feb5d407dc0e1ca40e9490c335cdd441607bdaf49f8c1bb0a5e0c7d

For other languages, we would want something similar - a generic way to mark what versions need to be updated.

@chingor13
Copy link
Contributor

Note: code search is a very expensive API call, so we cannot be consistently searching across all the source for a variety of patterns. Since the source file will likely differ from project to project, a configurable list of extra files to consider seems reasonable.

@chingor13
Copy link
Contributor

Also related to #305

@chingor13 chingor13 self-assigned this Dec 21, 2021
chingor13 added a commit that referenced this issue Dec 29, 2021
This introduces a new `Generic` updater class that scans the file line by line for annotations.

You can annotate a line (inline) via:
* `x-release-please-version`
* `x-release-please-major`
* `x-release-please-minor`
* `x-release-please-patch`

For these annotations, we will try to replace the value on that line only.

You can annotate a block by starting with a line containing:
* `x-release-please-start-version`
* `x-release-please-start-major`
* `x-release-please-start-minor`
* `x-release-please-start-patch`

and close the block with a line containing `x-release-please-end`. Within the block, we will attempt to replace version values.

Additionally, all basic strategies now support the `extra-files` option which will apply this generic updater class.

Fixes #435
Fixes #305
Fixes #1139
Fixes #1174
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants