search

audreyfeldroy / cookiecutter-pypackage

Cookiecutter template for a Python package.
BSD 3-Clause "New" or "Revised" License
4.24k stars 1.78k forks source link

Git Tags #55

Open reiz opened 9 years ago

reiz commented 9 years ago

This repository was submitted at VersionEye, but without tags there is not much to track. Why not creating a first snapshot tag. SemVer is a big help choosing the right version name ;-)

eliasdorneles commented 8 years ago

This is a good idea, I think we can start doing formal releases. We can even release source distributions to PyPI (so that people can find it if they search it).

reiz commented 8 years ago

That's a very good idea. If it is on PyPI, it is automatically on VersionEye as well and we don't need to crawl this git repo at all 👍

audreyfeldroy commented 8 years ago

Agreed. @katialira and I started working on this. We added a setup.py and bumpversion config in setup.cfg. What's left is configuring Travis CI and documenting the release process.

ssteinerx commented 7 years ago

@audreyr -- I'm posting this on the oldest ticket in the repo.

What's left is configuring Travis CI and documenting the release process.

I have a bunch of little packages to make over the next week or so and could spend a bit of time on this if it would help with closing up some of the many "version bump" and other trivial pull requests and issues.

For example:

131 references pip 7.1.2 vis-à-vis PyPy which references #130 (closed).

235 makes the pyup badge optional with a one-line configuration change and an if statement in the template. It really just needs a decision and a trivial merge if it's a go.

Let me know how I can help if you've got time to roll them up into a release when it's ready. I can only commit the time if it's going to result in a new release, otherwise it's just more "ToDo" on top of the existing ones and doesn't really accomplish anything.

Here's what I'd suggest:

First

1> Take the existing list of issues & pull requests, pull the "no longer relevant" tickets into a Release v0.1.2 checklist, and close them

2> Document the release process, run it, and have a no-code-changes-tidy-up-the-repo Release v0.1.2.

Even if that's all we have time for, this would clean up the issues and pull requests and make for a nice clean starting point for any further work.

Next

If there's time left, just do the updates to the requirements and close all those tickets, tweak up the release docs, and push another release out by following it.

Just these coupla' things will cut tickets/pull requests in about half or better.