Assist user in choosing the next release version number #2389

I think you can already know that 😉

would be cool to assist the user in choosing the correct version number based on semantic versioning, e.g. with buttons like 'next minor' or 'next major'.

It's better to use tools like https://github.com/semantic-release/semantic-release instead. If one chooses to bump versions by themselves, they should have the version number to go in mind (or they will go check commit list to make decisions).

You could also use the AJAX query the page is doing for the autocomplete when starting to type in the "Tag version" input.

https://github.com/<owner>/<repo>/tags?q=1

I am mostly using this autocomplete to find the last one and bump it.

---

If someone implements that, I really like the suggestion on semantic version enforcement. We can use 3 different inputs that you can only change with a ⬆️ button and you can bump a version segment maximum one time. If you bump one version segment, the ones on the right should be locked at 0.

Example

Current version: 3️⃣• 4️⃣• 5️⃣

When you open the new release page, you will see the following at first: 3️⃣⬆️ • 4️⃣⬆️ • 6️⃣ So the suggested next version by default is a patch release.

You can choose to bump either the major or minor version using the two up arrows:

If you click the first arrow up, it will change to: 4️⃣• 0️⃣• 0️⃣ So you will bump the major version.

If you have chosen to click the second arrow, it will have changed to:

3️⃣• 5️⃣• 0️⃣ So you will bump the minor version.

Notes:

• We need a reset button and some text explaining what's the previous version and a note what would be the change initially or after you click something.
• We need to read the previous tags and if they have a v prefix to include it in the new tag.
• We can later add numbered alpha, beta, rc suffix buttons.
• We can add a link to semantic versioning spec.
• We need to detect if the repo is not using semantic versioning and disable it.
• This workflow really helps with patch releases which are most common as you wouldn't need to change anything from the default state of the page on the version.

@lukehefson 👋 Do you think the above is a good user story for the papercuts team? I hope bringing you in like that on such requests is fine!

I suggest:

• Using np when possible

  <img src="https://raw.githubusercontent.com/sindresorhus/np/master/screenshot-ui.png" width="500">

• Showing a list of possible versions like np does, perhaps as an autocomplete dropdown that appears before the user starts typing, because then GitHub uses their own dropdown. Maybe patch, minor, major is enough.

  <img width="475" alt="" src="https://user-images.githubusercontent.com/1402241/64041337-66f80880-cb89-11e9-852d-2383171947ae.png">

We need a reset button and some text explaining what's the previous version and a note what would be the change initially or after you click something.

I'd rather show the latest version next to the field, to give some context (We already have this information from the branch-buttons feature btw), and not autofill the field.

We need to read the previous tags and if they have a v prefix to include it in the new tag.

👍

We can later add numbered alpha, beta, rc suffix buttons.

👎 Let the user add those details manually instead. Everyone will have different preferences and it makes no sense to venture into that (.dev, -0, -rc1, r3, .build.333)

We can add a link to semantic versioning spec.

👍 for informing the user.

We need to detect if the repo is not using semantic versioning and disable it.

👎 This feature is unrelated to semantic versioning, we'd just offer numbers. 1.0.0 becomes 1.0.1 whether they follow the semantic versioning spec or not.

This workflow really helps with patch releases which are most common as you wouldn't need to change anything from the default state of the page on the version.

👎 This is dangerous because pre-filling that field with a patch version might cause the user to release a major version as a patch by mistake, simply by forgetting to update the field.

I support everything @fregante said. I had doubts based on the same reasoning about defaults. I can see how a list is simpler to use and more abstract than bumping numbers.

I hope bringing you in like that on such requests is fine!

@hkdobrev Any time!

I think this is a super cool idea, but I wouldn't be able to make any comments as to if/when we might do something like it ourselves. I suspect that it's probably not within the realms of papercuts for us – but will make sure that it's tracked either way!

• We can add a link to semantic versioning spec.

I think GitHub already has this:

@muuvmuuv that's a cool UI that GitHub could offer, but Refined GitHub is mostly language-agnostic and can't support all of the package managers.

Since we can't support that, we can just use a simple dropdown like this (+ @staabm's suggestion):

<img width="475" alt="" src="https://user-images.githubusercontent.com/1402241/64041337-66f80880-cb89-11e9-852d-2383171947ae.png">

Small update: GitHub added a dropdown selector to select existing tags:

<img width="389" alt="Screen Shot 7" src="https://user-images.githubusercontent.com/1402241/130846699-18c1e8cb-d791-4260-9ded-9f1fa2e9b7aa.png">

This is somewhat helpful because now we have a native list of tags that we can relatively easily pick from. We can steal latest-tag-button’s logic to find the latest tag and add a +1 on each of the first 3 numbers, dropping the rest.

Note: This would be helpful on most repos and doesn't have to cater to complex tagging systems.

Note 2: Feature freeze is still in place.