{"action":"created","issue":{"url":"https://api.github.com/repos/mozilla/mozilla-django-oidc/issues/143","repository_url":"https://api.github.com/repos/mozilla/mozilla-django-oidc","labels_url":"https://api.github.com/repos/mozilla/mozilla-django-oidc/issues/143/labels{/name}","comments_url":"https://api.github.com/repos/mozilla/mozilla-django-oidc/issues/143/comments","events_url":"https://api.github.com/repos/mozilla/mozilla-django-oidc/issues/143/events","html_url":"https://github.com/mozilla/mozilla-django-oidc/issues/143","id":234864921,"number":143,"title":"Release for every feature/bug fix","user":{"login":"peterbe","id":26739,"avatar_url":"https://avatars1.githubusercontent.com/u/26739?v=3","gravatar_id":"","url":"https://api.github.com/users/peterbe","html_url":"https://github.com/peterbe","followers_url":"https://api.github.com/users/peterbe/followers","following_url":"https://api.github.com/users/peterbe/following{/other_user}","gists_url":"https://api.github.com/users/peterbe/gists{/gist_id}","starred_url":"https://api.github.com/users/peterbe/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/peterbe/subscriptions","organizations_url":"https://api.github.com/users/peterbe/orgs","repos_url":"https://api.github.com/users/peterbe/repos","events_url":"https://api.github.com/users/peterbe/events{/privacy}","received_events_url":"https://api.github.com/users/peterbe/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":7,"created_at":"2017-06-09T15:37:47Z","updated_at":"2017-06-12T13:36:25Z","closed_at":null,"body":"I propose we make releases more frequently. One release for every new feature or bug fix. That way, we don't have have a meeting and say \"Ok, what's changed since the last release?\" and type that up in `HISTORY.txt` along with a change to `mozilla_django_oidc/__init__.py`'s `__version__` string. \r\n\r\nIt is possible to encryt your PyPI password and put that in `.travis.yml` and let travis try to make a PyPI release on every successful build on origin/master. If the version number hasn't change, PyPI will simply respond with a gentle error like \"Sorry, that version already exists\". \r\nThat means if all you do is commit a change to the documentation or a style fix or a change only to the unit tests, no new PyPI release is made. [For example](https://github.com/peterbe/hashin/blob/master/.travis.yml#L21-L22).\r\n\r\nThis would require a change of how you make PRs. If your PR indeed contains a feature change or a bug fix, you're *also* expected to edit `HISTORY.txt` and `__init__.py` along with your change. \r\nIf two people make a PR based on version 1.2.3 and they both make PRs that change `HISTORY.txt` and `__init__.py` then it's likely to cause a conflict and the author has to rebase up. \r\n\r\nAnother option is to still set up travis to push to PyPI on every origin/master build, but NOT require PRs to contain a change to `HISTORY.txt` and `__init__.py`. Then once your feature/bug fix lands on master you make *another* PR that just edits `HISTORY.txt` and `__init__.py`. \r\n\r\nThoughts? Ideas? Objections? Endorsements?"},"comment":{"url":"https://api.github.com/repos/mozilla/mozilla-django-oidc/issues/comments/307791255","html_url":"https://github.com/mozilla/mozilla-django-oidc/issues/143#issuecomment-307791255","issue_url":"https://api.github.com/repos/mozilla/mozilla-django-oidc/issues/143","id":307791255,"user":{"login":"peterbe","id":26739,"avatar_url":"https://avatars1.githubusercontent.com/u/26739?v=3","gravatar_id":"","url":"https://api.github.com/users/peterbe","html_url":"https://github.com/peterbe","followers_url":"https://api.github.com/users/peterbe/followers","following_url":"https://api.github.com/users/peterbe/following{/other_user}","gists_url":"https://api.github.com/users/peterbe/gists{/gist_id}","starred_url":"https://api.github.com/users/peterbe/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/peterbe/subscriptions","organizations_url":"https://api.github.com/users/peterbe/orgs","repos_url":"https://api.github.com/users/peterbe/repos","events_url":"https://api.github.com/users/peterbe/events{/privacy}","received_events_url":"https://api.github.com/users/peterbe/received_events","type":"User","site_admin":false},"created_at":"2017-06-12T13:36:25Z","updated_at":"2017-06-12T13:36:25Z","body":"> \"Signed commits don't exactly carry the same information as signed tags\"\r\n\r\nThat was news to me. I don't think I still understand it but, this answers point 3. Tags it is. \r\n\r\nWhat you're also saying is that it's ok that Travis goes ahead and makes the deployment (based on the new tag). So that answers point 1 too. "}}
{"actor":{"display_login":"peterbe"}}