PyPI/pip won't have an issue; the problem will be in manual version
checking code. Case in point: in the current release code base:
https://github.com/jnwatson/py-lmdb/blob/py-lmdb_0.99/setup.py#L47
<https://github.com/jnwatson/py-lmdb/blob/master/setup.py#L47>
if sys.version[:3] < '2.7' or (sys.version_info[0] == 3 and sys.version[:3]
< '3.4'):
prevents py-lmdb from being installed on 3.10. (Already fixed in master,
and that's not the only problem for 3.10)
I'm not completely opposed to going to 1.0. The biggest open issue
(close/use race) doesn't have a fix that won't impact performance.
I don't currently see a need for any backwards incompatible changes, which
I guess is one argument for going to 1.0.
I appreciate that semantic versioning isn't a solution to a lot of
problems, but it does communicate some information. Importantly, it allows
one to make backwards incompatible changes and make the argument to your
upstream that you should constrain versions in your dependencies.
Nic
On Thu, Aug 13, 2020 at 8:04 PM Cameron Simpson <cs@xxxxxxxxxx> wrote:
On 13Aug2020 09:08, Nic Watson <py-lmdb@xxxxxxxxxxxxx> wrote:
Sorry for the delay. I've been expecting a new downstream release any day
now for the last 9 months. I'm done waiting.
Thank you!
Open issues:
* What to call the next version? .100 can be problematic for some version
checking.
Shouldn't be, given the PyPI version specification.
Personally I use date based release numbers to avoid this very problem.
0.99.1 ? Of course that may imply an overly minor release.
What's your threshold for 1.something ?
Cheers,
Cameron Simpson <cs@xxxxxxxxxx>
