Version releases

[jeremylow]

So I came across this thing while trying to upgrade the package using pip:

If you have (say) v3.1 installed from Github (like in your reqs file: -e git+https://github.com/bear/python-twitter@master#egg=python-twitter) and then we make a few commits here, and then you try to rerun pip install -r requirements.txt, nothing happens and pip thinks that the package is up to date (basically failing silently in my case since I assumed different behavior). Apparently, even specifying a specific commit (-e git+https://github.com/bear/python-twitter@[whatever]#egg=python-twitter) doesn't make pip realize that it should rebuild and reinstall the package.

This is a known thing with pip (pypa/pip#2837), but it probably won't get solved any time soon. So I'm wondering if we shouldn't be bumping the version number for bugs? This came up for me because of a rate limit thing that I swore I fixed, but it just turns out that pip was keeping the old 3.1 version around and not actually building from the master branch. It's kind of annoying since we also do feature development on the master branch - I don't know how to approach it really, but I thought I'd bring it up since I've closed issues thinking that the pip install from Github route was clearer/worked. Maybe a develop branch and cherry pick bug commits into master between feature releases?

[bear]

+1 as that would solve the issue for you.

I use a pip install that references a local directory for my virtualenv work so I don't see this issue and I can just as easily work from a branch checkout.

Given that we all use PRs to push now, cherry picking shouldn't be an issue

[jeremylow]

Sounds like a plan.

(How does your setup work?)