Add DATE field type and support for multiple array types - #1
Conversation
maroux
commented
Jul 20, 2020
thanks for the contribution @germanp173 |
techgerm
commented
Jul 20, 2020
@maroux thanks for the quick response! |
techgerm
commented
Jul 20, 2020
@maroux do you usually publish a new version to PyPi on every master merge or what is your cadence? |
So far it has been ad-hoc - will probably move to weekly at some point. Btw, if you are planning more work on this repo, 2 things you should know - this was originally forked from google/python-spanner-orm which is not taking any contributations (at least not actively), but I set this up as a new repo only because I plan to break compatibility with google's repo by re-indenting all the code here. Hate the 2-space indent that exists right now. Second - once the 2-space indent lands your in-progress PRs (if any) will require painful merging. However, I don't have any particular timeline in mind for this work, so if you have planned work, I can postpone the re-indent. I did have a few more changes in mind which I'll add to the README. |
Yup, I originally intended to use the On your 2-space indent point, totally on board with that! In our company, we use Also, are you open to setting up a GitHub action that automatically publishes a new version to PyPi (and tags repo) on master merges? I can help out with that if so. |
maroux
commented
Jul 20, 2020
@germanp173 yeah Github action for both 1. running tests and 2. publishing new version sounds good. Tests are
I usually do workflow 2 (with bumpversion / bump2version) but that does mean git commits are cluttered with "update version" commits which is a little annoying. I've been meaning to try out workflow 1 so we can do that with this repo if that sounds good. |
techgerm
commented
Jul 21, 2020
@maroux Actions for running tests and publishing would be great 💯 In your scenario 1, why not let GitHub actions push the commit so master is not out of date with reality? That's what we do in our company since we have the same situation where our npm packages hold the version in the |
maroux
commented
Jul 21, 2020
Well for repos that don't get a lot of commits, it tends to clutter git history by adding one additional version bump commit for every code commit but that's how most python repos look so not a big deal. Thinking some more - the trigger should probably be a PR submitted by a maintainer with some command-tag like |
techgerm
commented
Jul 21, 2020
I see and yeah that sounds better 👌 Side question, do you think I can get an estimate release date for the next release? Asking since we could really use those changes I made. |
maroux
commented
Jul 21, 2020
Done. |
techgerm
commented
Jul 21, 2020
Awesome thank you very much! |
No description provided.