update to gfx 0.8 - Githubissues

PistonDevelopers / gfx_text

Draw text for gfx using freetype

http://docs.piston.rs/gfx_text/gfx_text/

MIT License

22 stars 12 forks source link

update to gfx 0.8 #33

Closed ghost closed 8 years ago

bvssvni commented 8 years ago

Thanks!

Kagami commented 8 years ago

Thanks! Published gfx_text 0.6.0.

bvssvni commented 8 years ago

@Kagami Could you use PR instead of pushing directly next time? Makes it easier to know what's happening since I get an email about the update. Then I can re-run Eco to check everything is alright.

Kagami commented 8 years ago

Ok, no problem.

Kagami commented 8 years ago

@bvssvni do you prefer all commits to be landed via PR or just significant changes? It's a bit routine to create PR for e.g. every trivial change in readme.

bvssvni commented 8 years ago

@Kagami There is a direct push feature where you can make a PR from a temporary branch.

Kagami commented 8 years ago

@bvssvni elaborate please? Do you mean some feature of GitHub which can be enabled in project settings?

bvssvni commented 8 years ago

@Kagami When editing the README, you get two choices beside the commit button. One of them is to create another branch and do a PR.

Kagami commented 8 years ago

Ok, I tested it a bit and PRs for features are ok, but I think creating PR just for version bump is wrong.

git tag should point to exact commit, not to the merge
cargo publish should be made from exact same commit as git tag
version should be bumped only after everything was tested (e.g. docs, README formatting, etc), so it can't be part of another PR; and creating PR only for single line change is pointless

bvssvni commented 8 years ago

@Kagami We need a solution that doesn't require much work over time. Currently we do a PR for bumping versions (so people get an email), and use Eco to tell us the libraries that needs update. If you want to discuss this, please open up an issue on the piston repo.