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
fix: update pypi package name #454
Merged
Merged
Changes from 4 commits
Commits
Show all changes
13 commits
Select commit
Hold shift + click to select a range
3211cd0
feat: add PyPI release support
skuruppu 2d00f17
fix: update package name
skuruppu d2edb9b
deps: remove dependency on google-cloud
skuruppu 47da129
chore: added extra fields to setup.py
skuruppu ce6533e
fix: single-source the version
skuruppu a0aba52
fix: made setup.py consistent with client lib
skuruppu c8c61ce
fix: removed comment that no longer applies
skuruppu 251ee4a
fix: only support python version >=3.5
skuruppu 8514f00
add missing os import
larkee 596c107
add missing io import
larkee a11164e
fix README file extension
larkee 61b48cf
add missing pkg_resources import
larkee 2cecc5c
fix import ordering
larkee File filter
Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume release-please will replace this version since this doesn't look like the version number it's proposing in #453
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That wouldn't be ideal. The README explains the typical versioning of database backends: "Use the version of django-spanner that corresponds to your version of Django. For example, django-spanner 2.2.x works with Django 2.2.y. (This is the only supported version at this time.)"
The specifics of the alternate proposal are unclear but I'd think the maintenance burden and user confusion about which version to use would be higher.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@timgraham thanks for that info. But see my comment. There are lots of existing django packages that are published by Google and they all consistently use the versioning scheme used by release-please.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, sem-var versioning is typical for other Django libraries that often support multiple versions of Django. Database backends are different. The best practice is to create separate release branches for each version of Django that's supported.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I spoke to @larkee and they explained that the manual releasing won't be so painful.
@timgraham do you have any thoughts on the issue of pinning releases when you have non-semver versioning?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If using Django 2.2.x, use
django-google-spanner>=2.2,<3.0
. I thinkdjango-google-spanner==2.2.*
would be equivalent.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In that case, @timgraham or @odeke-em could you update the README to explain why the versioning is the way it is? Please include links to the Django README as a reference.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What I quoted is from the README in this repo.