noirbizarre / bumpr Goto Github PK

Hi 👊

This is my first visit to this fine repo, but it seems you have been working hard to keep all dependencies updated so far.

Once you have closed this issue, I'll create separate pull requests for every update as soon as I find one.

That's it for now!

Happy merging! 🤖

I think it's not OK

Hello,

I wonder if the result of check_output in the helpers.py file shouldn't be "decode()"d for python 3, i.e.

      output = subprocess.check_output(stderr=subprocess.STDOUT, *args, **kwargs)
      if sys.version_info.major==3:
          return output.decode()
      return output

When bumpr issues "git tag [tagname]" (in vcs.py) it should create an annotated tag (-a or --annotate).

Why?

• git best practice is for versions to be annotated tags.
• in some best practice configurations only annotated tags get pushed (see git followTags config).

So bumpr should only create annotated tags.

If backwards compatibility is an issue then at least an option to create annotated tags instead of the current behaviour to create lightweight tags should be added.

It appears that the changelog hook will perform replacements on the version in the given changelog file, but does not add the changes that should be a part of that version. It's possible that I'm doing something wrong and I've hit an edge-case, but I've looked at the python code, and I don't think that's true.

This should be feasible by scanning the git log and retrieving pieces of metadata for each commit (e.g. subject, short hash, author, etc.). Under that version header, this list could then be inserted between the previous and current release.

I think similar functionality has been implemented in other Python libraries, but so far those approaches seem a little heavy-handed. This feature seems like a natural extension to Bumpr, which already updates the changelog.

So far, I've managed to achieve the desired behavior by running a shell script from the commands hook, but this seems less than ideal. Personally, I think this would be a nice out-of-the-box feature.

I get this if I run bumpr and there's no conf file (I'm assuming that's the cause):

Traceback (most recent call last):
  File "/usr/local/bin/bumpr", line 11, in <module>
    sys.exit(main())
  File "/usr/local/lib/python2.7/dist-packages/bumpr/__init__.py", line 32, in main
    releaser = Releaser(config)
  File "/usr/local/lib/python2.7/dist-packages/bumpr/releaser.py", line 26, in __init__
    with open(config.file) as f:
TypeError: coercing to Unicode: need string or buffer, NoneType found

Deprecate tool.bumpr.ini_format introduced in #296 for a new tool.bumpr configuration format tied to toml.

Given the legacy bumpr.ini support should be removed (#298) in the same milestone,we are now free to rethink entirely the format 🎉

Hooks are configurable in their repsective sections llike tool.bumpr.replacements or tool.bumpr.readthedocs.

A common use case is to bump some changes on URLs on merge and ensure version is a particular one after the merge.

Given the way bumpr works, it should be really easy to make it handle merge.

Why it would benefit Bumpr:

The biggest reason to use twine is that python setup.py upload uploads files over plaintext. This means anytime you use it you expose your username and password to a MITM attack. Twine uses only verified TLS to upload to PyPI protecting your credentials from theft.

Secondly it allows you to precreate your distribution files. python setup.py upload only allows you to upload something that you've created in the same command invocation. This means that you cannot test the exact file you're going to upload to PyPI to ensure that it works before uploading it.

Finally it allows you to pre-sign your files and pass the .asc files into the command line invocation (twine upload twine-1.0.1.tar.gz twine-1.0.1.tar.gz.asc). This enables you to be assured that you're typing your gpg passphrase into gpg itself and not anything else since you will be the one directly executing gpg --detach-sign -a <filename>.

Link:

https://pypi.python.org/pypi/twine/

Follows #297

Rewrite the CLI API with forward compatibility in mind meaning:

• no more root command (but verb approach like bump, branch, merge, check...)
• configuration first (do not try to replicate each and every parameter as cli parameter)

If possible, keep the legacy API for 2 releases but warn and inform about the deprecation and removal timeline.

Store configuration in pyproject.toml file.
Configuration format should be the same and stored into the tool.bumpr.ini_options section (we use the same pattern as pytest to transition to pyproject.toml)

Superseedes #10

If we use prepare version we got:

-> Bump version 0.2.20
-> Prepare version 0.2.20.dev

I'd like to have other. Bumped patch part and suffix after minus.

-> Bump version 0.2.20
-> Prepare version 0.2.21-dev

Can I do that?

I would have expected bumpr to do a push after the "bump" and before the "prepare" phase (as part of the publish phase ?). But no push happens. So at the first push after a bumpr, both the "bump" and the "prepare" phase of the version are pushed immediately.
Would it make sense to have a push in between ?

There is no branch logic neither (like master and devel) in bumpr. Are there plans to support more advanced workflows (like doing a bumpr in the devel branch that does the merge/push/etc in the master) ?

Switch from raw argparse to Click which handle:

• proper color support
• proper testing support
• known edge cases

Bumpr signatures should be backward compatible.

If there is no changes in prepare phase, I get "nothing to commit" message and bumpr fail.

Can we have an option to skip prepare phase? or auto detect whether there is [prepare] section in bumpr.rc.

codecs.open doesn't support universal newlines, so it will fail to match text containing \n on Windows:
https://github.com/noirbizarre/bumpr/blob/master/bumpr/hooks.py#L93
https://github.com/noirbizarre/bumpr/blob/master/bumpr/hooks.py#L115

Maybe to use io.open?
http://stackoverflow.com/questions/35052346/reading-utf-8-file-with-universal-newlines-in-python-2

I would really like, and I expect other users of bumpr too, a hook to execute any command(s) we like after running bumpr.

Examples:

• git push
• git push --tags
• email mailing list.
• whatever...

These hooks should be "after" the version bump.

I tried the "commands" feature of bumpr and it did not work (executed probably before the bump and not after)

Displayed diff in prepare phase in dry run mode is wrong because it use the unmodified file from bump phase

If we use -dev as prepare version suffix we got endless raising suffix.
We got after few bumps:

version='0.2.20.-dev.-dev.-dev'

I didn't find Changelog section in Configuration file description

If we don't specify version part neither by param neither config file, but specify vcs param, bumpr try to commit with no changes.
I think it's good to set part to patch by default.

apihackers/devpi-semantic-ui#10

ini file is limited:

• it's not possible to handle list of objects (required for replacements)
• Python 2/3 implementation slightly differs (mostly when using setup.cfg)

On the opposite, yaml is typed, supported by all Python version with PyYaml, well known and support structured data.

So instead of using a bumpr.rc file or setup.cfg, bumpr will be using a bumpr.yml file.

Improve string replacement handling by providing an universal replacement hooks.
ReadtheDocs hooks should extends this one.

As soon as #296 is implemented, bumpr.iniconfiguration should be deprecated.

[bumpr]
verbose = True

Only command line -v works.