Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[MRG+1] Remove bumpversion prerelease configuration #2159

Merged
merged 1 commit into from Feb 20, 2017

Conversation

@eliasdorneles
Copy link
Member

@eliasdorneles eliasdorneles commented Aug 1, 2016

I propose to remove the prerelease configuration from bumpversion, because I think its behavior is just too confusing.

The rationale for this is that making the release procedure predictable is more important than facilitating making pre-releases, which are sort of the exception in the workflow.

The current configuration makes most common cases confusing:

  • bug fix releases require you have to remember to use --serialize "{major}.{minor}.{patch}"
  • to start a pre-release cycle, you actually use minor or patch
  • to do the actual minor or patch release, you use prerel

Also, prerel breaks if you run it on a branch with a final release, because it can't parse the prerelease information.

Therefore, I propose keeping the bumpversion defaults, and do the prereleases (dev1, dev2, rc1, etc) manually (with --new-version), which makes for a more predictable and intuitive behavior.

  • bumpversion minor and bumpversion patch will work as expected
  • pre-releases will be manually handled, but this seems a small overhead
    than remembering the details I mention above.

If you're happy with this, I'll also update the wiki with new instructions.

What do you think?

I propose to remove the prerelease configuration from bumpversion,
because I think its behavior is just too confusing.

The rational for this is that making the release procedure predictable
is more important than facilitating making pre-releases, which are sort
of the exception in the workflow.

The current configuration makes most common cases confusing:

* bug fix releases require you have to remember to use `--serialize "{major}.{minor}.{patch}"`
* to start a pre-release cycle, you actually use `minor` or `patch`
* to do the actual minor or patch release, you use `prerel`

Also, `prerel` breaks if you run it on a branch with a final release,
because it can't parse the prerelease information.

Therefore, I propose keeping the bumpversion defaults, and do the
prereleases (dev1, dev2, rc1, etc) manually (with `--new-version`),
which makes for a more predictable and intuitive behavior.

* `bumpversion minor` and `bumpversion patch` will work as expected
* pre-releases will be manually handled, but this seems a small overhead
  than remembering the details I mention above.

If you're happy with this, I'll also update [the wiki][1] with new
instructions.

[1]: https://github.com/scrapy/scrapy/wiki/Scrapy-release-procedure
@codecov-io
Copy link

@codecov-io codecov-io commented Aug 1, 2016

Current coverage is 83.45% (diff: 100%)

Merging #2159 into master will not change coverage

Powered by Codecov. Last update 2c9a38d...4eec053

@eliasdorneles
Copy link
Member Author

@eliasdorneles eliasdorneles commented Aug 1, 2016

To make the proposal more concrete, I've put in a gist what would be the new instructions for the release procedures in the wiki: https://gist.github.com/eliasdorneles/129447468ce61a2f6e3886dde3c14a41
Let me know if that makes sense.

@redapple
Copy link
Contributor

@redapple redapple commented Aug 1, 2016

I would suggest mentioning the major and minor versions release procedure first, and then talk about the RC case.
You can even use 1.2 as base (and releasing 1.3.0rc1 as example for RCs)

@eliasdorneles
Copy link
Member Author

@eliasdorneles eliasdorneles commented Aug 1, 2016

Hm, won't the major and minor only make sense after explaining the branching approach taken with the RCs?

@eliasdorneles
Copy link
Member Author

@eliasdorneles eliasdorneles commented Aug 1, 2016

By "major and minor", I actually meant "minor and patch".

@redapple
Copy link
Contributor

@redapple redapple commented Aug 1, 2016

Right, the branching approach needs to be explained and then illustrated with examples.
Actually, on the branching approach, I'm not sure we always need branching out when we do release candidates. We could, in the general case,:

  • keep working with master branch,
  • force version to some RC number initially,
  • increment along the way,
  • until there's a backward compatible change to be merged (or more generally, some change we do not want in the next release that the RC is going to become).

The pain with 1.1 branch and master 1.2dev is that we branched out very (too?) early, with master and 1.1 being essentially the same until recently.

@redapple redapple changed the title Remove bumpversion prerelease configuration [MRG+1] Remove bumpversion prerelease configuration Sep 7, 2016
@kmike
Copy link
Member

@kmike kmike commented Feb 2, 2017

@redapple @eliasdorneles this is all voodoo for me, feel free to merge :)

@dangra dangra added this to the v1.4 milestone Feb 20, 2017
@redapple redapple merged commit 1d80efd into master Feb 20, 2017
2 checks passed
2 checks passed
codecov/patch Coverage not affected when comparing 2c9a38d...4eec053
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@kmike kmike deleted the remove-prerelease-configuration branch Feb 20, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

5 participants
You can’t perform that action at this time.