Feature request: after creating a tag, make a pull request to bump the version number

[DilumAluthge]

When I used to manually create tags, after I created the tag I would bump the version number in Project.toml. For example, after making tag v1.0.0, I would change the version in Project.toml from version = "0.1.0" to version = "0.2.0-DEV".

Now that TagBot automatically creates tags for me, I find myself forgetting to bump the version number in Project.toml to the next -DEV version.

Would it be possible for TagBot to automatically open a pull request to bump the version number?

[DilumAluthge]

I imagine that many projects don't follow this convention. So maybe we make it an opt-in feature, based on a configuration file tagbot.toml located in the repository.

[fredrikekre]

How do you know 0.2.0 will be the next release?

[DilumAluthge]

That's a good point. My habit is to bump the minor version, and then if I realize later that I need to make a patch release, then I change it to 0.1.1-DEV manually. (Because for me personally, minor releases are more common, and patch releases are less common.)

But I guess it makes more sense for the TagBot PR to bump from 0.1.0 to 0.1.1-DEV. And then if the package maintainer realizes that the next release will be a minor release and not a patch release, they can manually change it from 0.1.1-DEV to 0.2.0-DEV.

[christopher-dG]

I'm kind of on the fence about this.

On one hand, it's a good practice to have a prerelease version when in development, but at the same time, very few people currently do it and it has no real effect that I know of.

I think that automatic PRs after every version registration would be considered spam by most people (myself included), so opt-in would definitely be the only way to go.

Having some hypothetical config file would make #24 a lot nicer too, you could store your template in that file to be used for every release, along with settings for other stuff that people have opinions about. e.g.

bump:
  enabled: true
  component: patch  # 1.0.0 => 1.0.1-DEV
  identifier: PRE  # 1.0.1-PRE
changelog:
  pr_authors: true
  template: |
    **{{pkg_name}} {{version}}] ({{date}})**

    [Diff since {{last_version}}]({{diff_link}})

    {{custom}} 

    **Merged PRs:**
    {{pull_requests}}

    **Closed issues:**
    {{issues}}

    --- 

    be sure to like and subscribe xd

[fredrikekre]

Yea, I think that the version number of the just released version is a just as good approximation of the "real" version as e.g. guessing 0.2.0. In most cases I think it will just be more annoying instead, e.g. if you have upper bounded on 0.1.0 you are probably compatible with 0.2.0-dev. It would be annoying if you had to bump your requirement to 0.2.0 when you don't even know if you are compatible with 0.2.0 final.

[DilumAluthge]

This is a great discussion.

On one hand, it's a good practice to have a prerelease version when in development, but at the same time, very few people currently do it and it has no real effect that I know of.

I agree that it's good practice. Perhaps if we make it easier to automatically bump the version number, more people would start doing it?

I think that automatic PRs after every version registration would be considered spam by most people (myself included), so opt-in would definitely be the only way to go.

It would absolutely have to be opt-in.

Having some hypothetical config file would make #24 a lot nicer too, you could store your template in that file to be used for every release, along with settings for other stuff that people have opinions about. e.g.

Yeah, I think regardless of whether or not we implement the "bump version number" feature, we should probably start supporting a configuration file. Since Pkg uses TOML files, we should probably use TOML to be consisting. I'm thinking tagbot.toml. So an example tagbot.toml file might look like this:

[bump]
enabled = true
increment = "patch" # 1.0.0 => 1.0.1-DEV
suffix = "-PRE" # 1.0.1-PRE

Yea, I think that the version number of the just released version is a just as good approximation of the "real" version as e.g. guessing 0.2.0. In most cases I think it will just be more annoying instead, e.g. if you have upper bounded on 0.1.0 you are probably compatible with 0.2.0-dev. It would be annoying if you had to bump your requirement to 0.2.0 when you don't even know if you are compatible with 0.2.0 final.

That's a good point. What if you upper bound to 0.1.x? And then in tagbot.toml, you would set bump.increment = "patch". So then the PR would bump you from 0.1.0 to 0.1.1-DEV, which would still be compatible with an upper bound of 0.1.x.

Alternatively, we could let people set the config so that they don't increment anything, and then do something like 0.1.0 => 0.1.0+POST or 0.1.0 => 0.1.0+DEV. tagbot.toml would look something like:

[bump]
enabled = true
increment = "none" 
suffix = "-PRE" # 0.1.0 => 0.1.0+POST

[DilumAluthge]

I'm working on a prototype of this. I'll make a pull request once it's functional.

[christopher-dG]

What's TOML's multiline string syntax like? If it's ugly I'd rather use YAML. Also please use a hidden file .tagbot.ext.

[christopher-dG]

(It's not as if YAML is foreign seeing as more or less everyone uses Travis CI)

[christopher-dG]

one last thing (apologies for the spam) -- it might be wise to wait a few days before digging into anything big because I'm moving a fair bit of code around to address #28.

[StefanKarpinski]

If it's ugly I'd rather use YAML.

Please no. Let's not add unnecessary config file format diversity to the Julia ecosystem.

[DilumAluthge]

What's TOML's multiline string syntax like? If it's ugly I'd rather use YAML. Also please use a hidden file .tagbot.ext.

From here, I believe it looks like this:

str1 = """
Roses are red
Violets are blue"""

(It's not as if YAML is foreign seeing as more or less everyone uses Travis CI)

That's a good point. So we could use either .tagbot.yml or .tagbot.toml. Probably doesn't make too much of a difference either way.

We will need to have a TOML parser as a dependency either way, because we need to parse Project.toml to get the current version number.

[StefanKarpinski]

Another option would be to put a [tagbot] section in Project.toml.

[christopher-dG]

FYI, the SemVer spec with respect to prereleases says that they should always be separated by a hyphen, so I'd go with bump.suffix = "pre" rather than "-pre".

https://semver.org/#spec-item-9

[DilumAluthge]

Yep that's what I originally envisioned.

I guess the question is: do we want to support users that want to bump from 0.1.0 to 0.1.0+POST? Since everything after the plus sign (the "build metadata") is ignored when comparing versions, this would allow users to side-step the issue Fredrik brought up:

Yea, I think that the version number of the just released version is a just as good approximation of the "real" version as e.g. guessing 0.2.0. In most cases I think it will just be more annoying instead, e.g. if you have upper bounded on 0.1.0 you are probably compatible with 0.2.0-dev. It would be annoying if you had to bump your requirement to 0.2.0 when you don't even know if you are compatible with 0.2.0 final.

[christopher-dG]

Are we considering the hypothetical situation where a package with a dep upper-bounded wants to depend on/test out that dep's master branch? As far as I can tell there are no situations where a version with a prerelease or build component will ever be registered.

I don't think we should be touching the build metadata because it's not meant for what we're doing. If people follow SemVer (a tough ask, I know), then there should be no reason for people to be upper-bounding dependencies on minor versions and this problem would not appear.

I might be misunderstanding though.

[DilumAluthge]

I.e if you are upper bounded on 0.1.0, then you can still use 0.1.0+POST. From Pkg’s point of view there is no difference. But any human that looks at Project.toml would realize that they aren’t working with a tagged release.

[StefanKarpinski]

I'm not sure about the idea of having a config file for this. Don't you sometimes want to make patch or minor increments under different circumstances?

[christopher-dG]

I.e if you are upper bounded on 0.1.0, then you can still use 0.1.0+POST. From Pkg’s point of view there is no difference. But any human that looks at Project.toml would realize that they aren’t working with a tagged release.

But putting that 0.1.0+POST in your Project.toml would not work because that version would never be registered, right?

[DilumAluthge]

Yeah it’s probably best if we only support this for people that use semver. And thus we’d only support things like 1.0.0=>1.0.1-DEV, 1.0.0=>1.1.0-DEV, and 1.0.0=>2.0.0-DEV.

I'm not sure about the idea of having a config file for this. Don't you sometimes want to make patch or minor increments under different circumstances?

I guess it depends on the practices of each specific project, right? For example, AFAICT in the Julia language repo, the practice is that the VERSION file in between releases has bumped the minor version. (Currently it reads 1.3.0-DEV.)

On Thu, May 30, 2019 at 01:11 Chris de Graaf notifications@github.com wrote:

I.e if you are upper bounded on 0.1.0, then you can still use 0.1.0+POST. From Pkg’s point of view there is no difference. But any human that looks at Project.toml would realize that they aren’t working with a tagged release.

But putting that 0.1.0+POST in your Project.toml would not work because that version would never be registered, right?

— You are receiving this because you authored the thread.

Reply to this email directly, view it on GitHub https://github.com/JuliaRegistries/TagBot/issues/27?email_source=notifications&email_token=ABK4BLKUVP2TAVASMDQLSHTPX5OX7A5CNFSM4HP6Y3KKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWRL5XI#issuecomment-497204957, or mute the thread https://github.com/notifications/unsubscribe-auth/ABK4BLLUB3ZJ4DZPIXTQWYTPX5OX7ANCNFSM4HP6Y3KA .

[christopher-dG]

I'm not sure about the idea of having a config file for this. Don't you sometimes want to make patch or minor increments under different circumstances?

This makes me wonder if maybe a command along the lines of TagBot bump major|minor|patch would be a better workflow. But we could probably support both.

[StefanKarpinski]

For example, AFAICT in the Julia language repo, the practice is that the VERSION file in between releases has bumped the minor version. (Currently it reads 1.3.0-DEV.)

That depends on what the next planned release is. On the release-1.1 branch, the VERSION file is 1.1.2-pre. On master it's 1.3.0-DEV. I'm not entirely clear why we're using -pre for the release branch and -DEV for the master branch—is that because there are no alphas or betas planned for the release branch? Seems like it would be better to use -DEV everywhere. Can you clarify, @ararslan?

[ararslan]

It's effectively a distinction in stability. -pre is "prerelease," which basically signifies that it should most likely be safe to just use; there are no alphas, release candidates, etc. for prereleases because there don't need to be any. On the other hand, -DEV is "in development," which means it's less safe, like using a nightly binary. Should probably be documented somewhere, I guess on the downloads page?

[christopher-dG]

only slightly related to this issue but before i forget, another use case of a config file would be storing changelog generator options that are currently hardcoded, such as section configuration. for example, you can set some labels whose issues/prs will be put into specific sections such as "enhancements" in the changelog. currently all those extra sections are disabled to be more "one-size-fits-all" but they don't need to be.