pytransitions / transitions

A lightweight, object-oriented finite state machine implementation in Python with many extensions
MIT License
5.49k stars 524 forks source link

Start using semantic versioning #558

Closed Kaju-Bubanja closed 2 years ago

Kaju-Bubanja commented 2 years ago

Is your feature request related to a problem? Please describe. Following code Machine(on_exception="on_exception") in transitions 0.8.7 gives below stacktrace:

Traceback (most recent call last):
  File "/home/username/PycharmProjects/app/lib/python3.8/site-packages/transitions/core.py", line 537, in __init__
    super(Machine, self).__init__(**kwargs)
TypeError: object.__init__() takes exactly one argument (the instance to initialize)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/username/.config/JetBrains/PyCharm2021.2/scratches/scratch.py", line 5, in <module>
    Machine(on_exception="on_exception")
  File "/home/username/PycharmProjects/app/lib/python3.8/site-packages/transitions/core.py", line 539, in __init__
    raise ValueError('Passing arguments {0} caused an inheritance error: {1}'.format(kwargs.keys(), err))
ValueError: Passing arguments dict_keys(['on_exception']) caused an inheritance error: object.__init__() takes exactly one argument (the instance to initialize)

Process finished with exit code 1

Describe the solution you'd like It would be nice if transitions would adhere to semantic versioning. Because this error is fixed in 0.8.10. At first I compared versions and saw that both instances are 0.8. So I thought it can't be that, after some further investigation I realized that the instance I had the issue on is 0.8.7 and the correctly running one is 0.8.10. This is somewhat surprising, since most libraries which use versions like x.x.x use semver usually and thus don't add new features in the last version number.

Additional context Awesome library :)

aleneum commented 2 years ago

Hello @Kaju-Bubanja,

we do use semantic versioning ;):

Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

even though we will keep the public API stable as far as possible. Bigger changes will usually result in a new MINOR version. After the release of 0.9, it is about time to consider releasing a 1.0 version though. I am not 100 percent happy about async code redundancy and HSM code complexity as of now, so there might be a 0.10 before a 1.0 hits PyPI.

I do appreciate the feedback and will consider releasing MINOR versions more often and reserve PATCH for actual (bug) fixes. If not right away then for sure after 1.0.0 has been released.

Until then, you can check the Changelog for a concise overview of what has been changed.

Kaju-Bubanja commented 2 years ago

I guess I always used 1.x.x libraries and thus didn't even realize that part of the spec. Today I learned :)