About pre-releases

We can accept something like:

cargo v 2.0.0-alpha.1
cargo v 2.0.0-beta.1
cargo v 2.0.0-rc.1

Only full versions should be accepted, and the major version defined must be greater than the current version.

Instead of panic!, we should show more friendly error messages.

Let's do some refactoring in our code following the tips from @togglebyte:

Part 1: https://www.twitch.tv/videos/1497045321
Part 2: https://www.twitch.tv/videos/1497077319

• Improve the way we communicate how the CLI works (maybe using a table instead of long descriptions)
• In documentation, make it clear that a commit and a git tag will be created, so before using cargo-v, the dev should make sure that there is nothing else to commit, and the project is building properly.
• Write error messages starting with lowercase letters
• Maybe a single letter for CLI is not a good ideia (but ver and version are already taken, so, I'm open to suggestions :D)
• Fix cargo clippy warnings
• Have to continue from here

Create a documentation on README.md and using Rust comments.

About metadata

Current version must remain the same and precedence must be ignored.

Examples:

Current version: 2.0.0

• Command: cargo v meta 123456.1.8.9
• Result: 2.0.0+123456.1.8.9

Current version: 2.0.0-alpha.1

• Command: cargo v meta git.123456
• Result: 2.0.0-alpha.1+git.123456

Current version: 2.0.0

• Command: cargo v meta git.123456-abc.1.2-890.1
• Result: 2.0.0+git.123456-abc.1.2-890.1

• Action: https://allcontributors.org/
• Website: https://allcontributors.org/

We should accept the labels alpha, beta and rc labels (using this precedence).

Examples:

cargo v alpha

This command will add a -alpha.1 next to patch version or increase the number after -alpha..

• If current version is 1.0.0, the result must be 1.0.0-alpha.1.
• If current version is 1.0.0-alpha.2, the result must be 1.0.0-alpha.3;
• If current version is 1.0.0-beta.1, the command above should result in an error: you can't decrease a version.

The same can be done with beta and rc labels.

• Dependencies in Cargo.toml can have a version entry. We should not change this version, only the version inside the [package] section.
• Update the version inside Cargo.lock without a build.
• Update src/lib.rs to use our parser.
• Stop using build to update Cargo.lock
• Export all functions from parser to import from cargo_v (pub use parser::* in src/lib.rs)
• Update src/main.rs to use our parser.

cargo-v should git tag -a v1.0.0 -m "v1.0.0" when new version is 1.0.0.

cargo-v CLI should read the file Cargo.toml and accept patch, minor and major as arguments:

# In version 0.0.1, should increment the latest number to 0.0.2
cargo v patch

# In version 0.0.2, should increment the second number and reset the latest one to 0.1.0
cargo v minor

# In version 0.1.1, should increment the first number and reset the second and latest ones to 1.0.0
cargo v major

• Move Config to its own crate;
• Move questions to its own crate;
• Documentation for -y option.

Accept partial versions, and fill up with the trailling zeroes: 1 and 1.0 means 1.0.0. 1.2 means 1.2.0.

https://doc.rust-lang.org/cargo/reference/manifest.html#package-metadata

cargo-v should git add and git commit -m "v1.0.0" when new version is 1.0.0.

After we run cargo v <version>, before create commit and git tag, we should ask some questions:

• All important files are git added and commited (specially Cargo.toml and Cargo.lock)? [Y]es [N]o
• Have you already run the command cargo build? [Y]es [N]o
• ?

After all y answers, we can continue safely. If any No is answered, we should abort.

We can add an Operation option -y or --yes to automatically answer Yes for all questions.

cargo-v CLI should read the file Cargo.toml and accept a manual version that may or may not start with v:

# The two following examples should have the same behaviour (always add a `v`):
cargo v v1.0.0
cargo v 1.0.0

We must ensure that the input version is greater than the current version.

The CLI should show how to use itself if --help argument is passed.