[MRG+1] Remove bumpversion prerelease configuration #2159
Conversation
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
Current coverage is 83.45% (diff: 100%)
|
|
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 |
|
I would suggest mentioning the major and minor versions release procedure first, and then talk about the RC case. |
|
Hm, won't the major and minor only make sense after explaining the branching approach taken with the RCs? |
|
By "major and minor", I actually meant "minor and patch". |
|
Right, the branching approach needs to be explained and then illustrated with examples.
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
changed the title
|
@redapple @eliasdorneles this is all voodoo for me, feel free to merge :) |
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:
--serialize "{major}.{minor}.{patch}"minororpatchprerelAlso,
prerelbreaks 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 minorandbumpversion patchwill work as expectedthan 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?