Is there a way to use pyhist with version numbers like "1.0.0b1" for pre-releases?

[bastienboutonnet]

I was looking for a way to generate nice changelogs without sweating and since I use conventional commits this looks like a good package.

Howwver, I'm not using absolutely strict semver whereby I have pre-release info like 1.0.1a1 etc.

Doing pyhist init crashed because of the non int.

I was wondering if there was any plan/willingness to support this kind of versioning?

If so, I might be totally happy to help contribute. Lemme know!

[jgoodman8]

Thanks a lot for your interest in the project, @bastienboutonnet!

Yes, the support of pre-releases and specific tags are in the support plan. This is just the very first release.
The idea would be providing something similar to what the standard-version CLI provides. For example:

Release as Pre-Release

pyhist --update --prerelease  # 1.0.0 -> 1.0.0-0
pyhist --update --prerelease alpha  # 1.0.0 -> 1.0.0-alpha.0

Release as specific version

pyhist --update --release-as 1.1.1a1  # 1.0.0 -> 1.0.0-1a1

If you want, you are completely free to contribute. Let's keep talking

[bastienboutonnet]

Awesome at least if it's on the radar means you're not against it hehe

Yep I'd love to contribute. From what I was able to see is that at the moment the functions that parse the versions are pretty strict. Would it make sense to allow them first to parse string like stuff?

What do you see might be the best way to have a stab at it.

Also am I right that update also acts as a bump version like thing? (I'm on my phone so it's shitty to check code right now) but yes would love to help!

[jgoodman8]

Sorry for my late response.

Yes, indeed the update command acts as a version bump.

I haven't seen the output error when you execute pyhist init, but I guess it's due to the parse of the current version. Currently, this is how the setup.py version is parsed:

def get_current_version_parts(self) -> Tuple[int, int, int]:
    version_str = self._get_version_str()
    return [int(version_part) for version_part in version_str.split(".")]

To support "custom" versions, we would need to change a couple of things:

• differentiate standard versions and custom versions in history
• change version parse method
• change init method
• add update to a specific version

[bastienboutonnet]

No worries at all @jgoodman8

The error output, which I don't have handy right now, was indeed coming from this part of the stack I believe, at least it looks familiar.

It seems pretty "straighforward". If you're into it I could try and find some time to have a go at it some day (probably next weekend or so)

[jgoodman8]

It would be great @bastienboutonnet
Please, let me know if you have any doubts or questions.

[bastienboutonnet]

No woeries!

A quick one. Can you rephrase or elaborate the first todo/bullet point you made in your last message? I think the other 3 are clear to me but not sure about the first.

[jgoodman8]

Yep, I think it's the trickiest.
It's a big complex to write it down. So, I will try to work on the first point during this week, sounds good?

[bastienboutonnet]

@jgoodman8 sure no worries and no rush! I can take care of the rest after :)