Jedi: Bump version to 1.0

[tim-win]

This library is used by major development and data science houses around the globe- it is very much 'in production'. This seems like as good a time as any to bump to version 1.0.

Rationale

Semver.org lays down good practices for release versioning, and it's pretty explicit: breaking changes in major version 0.X.X are totally acceptable:

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

However, jedi is widely used and relied on by huge numbers of people, as evidenced by the recent breaking changes in 0.18.0 requiring several build teams to scramble over the past two weeks.

Requested Changes

Bump package version to 1.0.0 and go through the release process. Also, follow Semver.org's guidelines for changes when possible going forward:

1. MAJOR version when you make incompatible API changes,
2. MINOR version when you add functionality in a backwards compatible manner, and
3. PATCH version when you make backwards compatible bug fixes.

Additional Note

I strongly recommend _against_ waiting for a new big feature or capstone piece of functionality to move a library to 1.0. There is _rarely_ an instance where that is warranted- once a library gets used by several teams let alone outside of an organization, good versioning practices are a form of communication, rather than a way to count milestones (for that, just look at your downloads!).

[davidhalter]

This will happen whenever Jedi is ready.

For further information, please read the release notes.

[tim-win]

I started another new project today, and ran into this issue again.

@davidhalter Do you have a timeline for version 1.0, as you state this is coming soon in the 0.18.0 release notes? I'm concerned you fell into the trap mentioned in "additional notes" of this issue- proper versioning is important communication tool between authors and users, it is a mistake to think of it as a milestone when a library is already in use and poor release management is already causing issues.

[tim-win]

Even better- as the release notes state that 0.18.0 is likely the last release before 1.0.0, do you recommend users pin to jedi>=0.18.0,<1 in their code? Or do you plan on making more breaking changes before the 1.0.0 release?

[davidhalter]

I started another new project today, and ran into this issue again.

So? This is not a big deal. If you want stable software, use Debian stable. If you depend on latest Pip releases just don't be surprised that sometimes things don't work.

@davidhalter Do you have a timeline for version 1.0, as you state this is coming soon in the 0.18.0 release notes? I'm concerned you fell into the trap mentioned in "additional notes" of this issue- proper versioning is important communication tool between authors and users, it is a mistake to think of it as a milestone when a library is already in use and poor release management is already causing issues.

Jedi is using proper versioning. It has always used proper versioning.

it is a mistake to think of it as a milestone when a library is already in use and poor release management is already causing issues.

I have never told anyone that the Jedi's API is in 1.0 shape. It truly never was. This is the first time that one could say such a thing. Jedi has always deprecated old APIs. I don't think there's much more you can do. It's not better for users to have version 25 of if the software still sucks. I'd rather have a version 0.120.0, because that's kind of what it actually is. Jedi has been in an initial development phase for 8 years. Naturally it would have been faster if I had the funds to work full time on it.

No offense Tim, but I think your approach towards working with Open Source is completely wrong. This is a collaborative field not one where you can shame maintainers into doing what you want. This is my hobby. You or your company did not pay me a cent for this. If you want to see change in the field, be the change. There's nothing stopping you from contributing towards Open Source projects, but I don't see you doing that.

Worst of it all your employer is a company that I would not even sell my code to, because it does not correspond to my ethics (feel free to read Chomsky's Manufacturing Consent or Slavoj Zizek in general). So if you don't use Jedi anymore at that company it is a win in my book. However it actually makes me rethink releasing my Rust software as MIT. I might have to modify that license so it cannot be legally used for certain purposes.

Note that I don't have a problem with you. My little daughter looks a bit like your kid. :) I think we could have a perfectly good time drinking a beer together. In fact if you're ever in Switzerland (Zurich area), feel free to hit me up and I'll invite you for a beer.

~ Dave

[tim-win]

I spun up a new virtual environment today for testing, and again ran into this issue. I'm sorry if this comes across as shaming, but sharing the impact of the issue with the author/maintainer is important. When I run into the issue again I add another comment to the closed issue, this seems like an acceptable way to share impact.

Can you please answer this questions I posted earlier?

Do you have a timeline for version 1.0

as the release notes state that 0.18.0 is likely the last release before 1.0.0, do you recommend users pin to jedi>=0.18.0,<1 in their code? Or do you plan on making more breaking changes before the 1.0.0 release?

[MarkWieczorek]

As part of releasing version 1.0, I would suggest moving this project from a personal repo to an organization.

[davidhalter]

Can you please answer this questions I posted earlier?

@tim-win How about you read Slavoj Zizek's book "Violence" and then I answer your question? :)

As part of releasing version 1.0, I would suggest moving this project from a personal repo to an organization.

What is this supposed to solve? Marketing? Essentially you are probably trying to fix the issue of maintainers/contributors. But in my experience small/medium open source projects like Jedi are usually one man businesses. I'm extremely happy that Peter is contributing regularly, but this is new and an exception. Before that it was only me for 8 years.

[MarkWieczorek]

It was just a suggestion. I don't think that anyone realized that this project was mission critical until the 0.18 release, and mission critical software usually shouldn't be a one man business. The community really should give you as much help as you need.