Smart_open: No matching distribution found for smart-open==1.8.1

[hexvolt]

Could you upload new version to PyPi please? Thanks

[mpenkov]

We will upload in the next day or so. I'll post again here once it's done.

[piskvorky]

@hexvolt where did you get / see this error? Can you provide context?

[mpenkov]

@piskvorky I suspect they did pip install smart_open==1.8.1 or something similar.

@hexvolt We've uploaded to PyPI, please retry.

[hexvolt]

@mpenkov @piskvorky
yes, exactly pip install smart_open==1.8.1. And pip install smart-open used to install 1.8.0 as a latest version. It works now, thanks a lot! The new version features are very handy.

[piskvorky]

@mpenkov is this really a bug fix release? Looking at the release notes, there are significant new features (implying 1.9.0), or even 2.0 because of that backward-incompatible open() change in top API.

I worry that presenting this as a mere bug-fix release may be misleading.

[mpenkov]

There's nothing backwards incompatible about this release. Open is a new function in the API. The existing smart_open function works the same as before, preserving backwards compatibility, with the only visible change in behavior being a deprecation warning.

We added some minor features, like the compressor registry, but they don't really justify a major release imho.

[piskvorky]

They do justify minor release though, IMO. This doesn't look like a bugfix release.

I mean, it's already done, but a note for the future.

[mpenkov]

Ok, how about instead of doing 1.8.2 to fix the xz stuff, we release 1.9.0?

[mpenkov]

@piskvorky I'd like to make a new release soon to resolve the problem in this ticket, can you let me know which you prefer:

1. Release as 1.9.0
2. Release as 1.8.2
3. Something else?

[piskvorky]

@mpenkov sorry, I was on holiday this week. Super impressed to see the amount of work (and notifications) you managed to produce in the mean while :-)

My preference here: 1.8.2.

My preference in general:

• incrementing bugfix (1.8.X) for innocuous changes and bug fixes
• incrementing minor (1.X.0) for anything more serious, new features
• major bumps (2.0.0) for API rewrites (but not necessarily when dropping an odd deprecated API param, as 100% strict semver would dictate -- I personally would find that confusing and silly).

Good release notes and migration instructions are IMO more important and useful, I see the versioning components more as quick hints.

Let me know your thoughts or suggestions, I'd like us to be on the same boat wrt versioning.

[mpenkov]

@piskvorky In general, I agree with your preference. For the next couple of releases, I'll double check the version number with you before proceeding.