On Jul 26, 2019, at 04:57, Sardorbek Imomaliev <sardorbek.imomal...@gmail.com> wrote: > > In the era of 0.x software https://0ver.org I think it is not feasible to > always wait till some standard, library or software becomes 1.x,
I think _in general_ waiting for 1.0 makes sense. Many projects don’t make any compatibility promises until 1.0 (think YAML 0.9). But different projects use version numbers differently. And TOML says: > As of version 0.5.0, TOML should be considered extremely stable. The goal is > for version 1.0.0 to be backwards compatible (as much as humanly possible) > with version 0.5.0. All implementations are strongly encouraged to become > 0.5.0 compatible so that the transition to 1.0.0 will be simple when that > happens. And that’s been the official word unchanged for over a year now, so they seem serious about this. > Standard library evolves and grows. But it evolves and grows slowly—not only on an 18-month cycle, but with strict rules about backward compatibility, and arguments about any substantial improvements. Would you be happy using today’s TOML library, with nothing but minor fixes, in 3 years? If not, you shouldn’t want it in the stdlib. Lots of libraries that lots of people need still need to evolve rapidly or independently. A big reason for working so hard on the pip ecosystem is so things like requests or numpy can be there for millions of users without having to get pulled into the stdlib to die. And, even if the packaging tools need it, and can freeze on an existing version and a specific subset of functionality, that still isn’t necessarily a reason to pull it in. It could be treated like requests: setuptools/pip/ensurepip bundle a version of requests internally, while end users can install a newer (or a specific) version in site-packages so they aren’t burdened by the release cycle. Would that not be appropriate for the way packaging needs TOML? _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/5DIT6RK6VTV2THBWNZZ5V4FP6VTKE36S/ Code of Conduct: http://python.org/psf/codeofconduct/
