Bump up version number to 2.5.0.dev

[HideakiImamura]

Motivation

We discussed versioning operations in our committers. Currently, we bump up the version just before the release. However, other OSS (e.g. PyTorch) have a postfix of dev or a for the next release version during development. This PR declares a change in versioning as well as a change in future versioning operations.

[hvy]

Sounds good I think. We haven't as far as I know ever defined what the version should refer to between releases.

[hvy]

What are the rules for including a dot here? I noticed some frameworks do, but I also remember discussing whether to include a hyphen before with @toshihikoyanase when releasing the RC for v2.0. We decided then based on other frameworks including TensorFlow, PyTorch, and other sources (if I remember correctly) to

1. Exclude the hyphen from the versioning https://github.com/optuna/optuna/blob/v2.0.0-rc0/optuna/version.py
2. Include the hyphen in the branch name/tag https://github.com/optuna/optuna/releases/tag/v2.0.0-rc0

Should we apply this rule here as well?

[hvy]

It's seemingly covered by PEP and should be included https://www.python.org/dev/peps/pep-0440/#public-version-identifiers

[HideakiImamura]

Thanks for the careful consideration and investigation. I followed pytorch-ignite which releases very frequently such as 0.2.0.dev2020xxxx. So, the current PR's versioning is fine according to the PeP 440?

[hvy]

Yup, it's complying.

From the PEP.

Development release separators
Development releases allow a ., -, or a _ separator as well as omitting the separator all together. The normal form of this is with the . separator. This allows versions such as 1.2-dev2 or 1.2dev2 which normalize to 1.2.dev2.

Implicit development release number
Development releases allow omitting the numeral in which case it is implicitly assumed to be 0. The normal form for this is to include the 0 explicitly. This allows versions such as 1.2.dev which is normalized to 1.2.dev0.

[toshihikoyanase]

@c-bata @himkt @keisuke-umezawa @crcrpar This PR will change Optuna's versioning rule. Please feel free to add any comments if you have any concerns.

[hvy]

LGTM!

For the record, this change will in practice only affect checkouts of the master branch, and CI/test uploads to PyPI's test environment. Official releases will be versioned as it always has.

[toshihikoyanase]

The change looks good to me.

[Note 1] When we build the distribution package, .dev will be converted to .dev0 as follows:

• optuna-2.5.0.dev0-py3-none-any.whl
• optuna-2.5.0.dev0.tar.gz

[Note 2] The version 2.5.0.dev is identical to 2.5.0.dev0 for packaging.version as follows:

>>> version.parse("2.5.0.dev") < version.parse("2.5.0.dev0")
False
>>> version.parse("2.5.0.dev") > version.parse("2.5.0.dev0")
False
>>> version.parse("2.5.0.dev") == version.parse("2.5.0.dev0")
True
>>> version.parse("2.5.0.dev") < version.parse("2.5.0.dev1")
True