Allow pre-release versioning about keepachangelog HOT 6 CLOSED

Hello @justin-richert ,

Can you provide a sample of markdown content so that I can reproduce it and see what we can do from here?

Thanks again

from keepachangelog.

Sure!

# Changelog
All notable changes to this project will be documened in this file.

The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).

## [Unreleased]

## [2.5.0b52] - 2021-04-21
### Changed
- Default Vary header now set on all responses for aiohttp apps
- ETag header logic for collection responses updated to indicate weak ETags

## [2.5.0b51] - 2021-04-21
### Fixed
- nginx container health check route in aiohttp kube deployment yaml was incorrect

This is probably a little bit of a bad example. I did go to semver.org and saw that the format defined there is actually this: 1.0.0-beta.1 instead of the way I have it. I think I pulled my formatting from PyPI's documentation, but I'm pretty sure their implementation is flexible enough to handle things like 1.0.0-beta.1 instead if you prefer to go the formal SemVer route.

Let me know if I can be of any help!

from keepachangelog.

Seems linked to #24

from keepachangelog.

@justin-richert there is no way we can properly automate bumping pre-release or release metadata information. As it is up to the user. In your case indeed it's easy to handle as you are incrementing an integer, but semver could also be used in the pre-release information as in X.Y.Z-dev.A.B.C. So I would rather avoid opening this door.

New version will however handle this kind of version and by default bump to a stable version.

If you want to be able to bump to a specific non-stable version, then I will add the ability to provide the new version yourself.
You would then be able to implement your own logic by:

1. Retrieving latest version (2.5.0b52 in your case)
2. Bumping pre-release to 53 by incrementing it (as it will be available in the semantic_version dict that will be introduced in #24 )
3. Provide this new version to the release function.

I think this will cover all possible use case and still keep the project maintainable enough :)

from keepachangelog.

This is now in develop branch and will be part of next release

from keepachangelog.

@Colin-b Awesome. I think this is a perfect and simple solution. Thanks for spending time thinking about the problem and developing a solution for it. I appreciate your time!

from keepachangelog.