Before committing to 1.0 for the Ruby library, I want to switch from positional to keyword arguments (with proper backwards compatibility and deprecation warnings of course), as current practice of having 3–6 positional arguments makes it hard to use and maintain the library. I am currently working on the implementation of the Configuration spec, and adding 7th positional argument is just unbearable.
Will try to draft a change for the public interface migration in the coming days. -- Dmytro Shteflyuk On May 2, 2026 at 10:47:49 AM, Yuxuan 'fishy' Wang ([email protected]) wrote: Not against it, but just want to call out that this is a serious commitment :) I'm not sure about other languages, but at least for Go, this means that for lib/go/thrift directory, once we are on v1.0.0, we cannot remove any public API, we cannot change any function signature of any public API. Doing any of those would require us to tag v2.x. (we can still mark an API as deprecated instead of removing it to be compliant with semvar) Looking back at the recent history, the Go api does stabilize over the past few years, so maybe it is time to commit to v1. But we certainly want to do another round of audit to make sure we make all the API changes we want to make before tagging v1. I would also suggest to go through some lengthy alpha/beta (e.g. git tag v1.0.0-alpha1) process before stable v1 tag, but not sure how that works with Apache's release policy. On Sat, May 2, 2026 at 1:49 AM Volodymyr Panivko <[email protected]> wrote: > Hi all, > > > > > With 0.23.0 out and 0.24.0 in active development, I'd like to open a > discussion on whether the next release should be tagged 1.0.0 instead of > continuing the 0.x line. > > > > A few reasons it feels overdue: > > > > > 1. Maturity. Thrift has been a top-level Apache project since 2010. The > wire protocol, IDL, and language libraries are stable in practice — > downstream users already treat them as > 1.x. > 2. Mixed signals. composer.json for the PHP library already declares > "dev-master": "1.0.x-dev" via branch-alias, so part of the project is > preparing for 1.0 internally — but releases > keep going out as 0.x. > > > 3. Semver mismatch. Per semver, 0.x means "anything may change at any > time." That no longer matches reality. Tagging 1.0.0 is the standard way to > communicate "production-ready, > semver compatibility going forward." > > > 4. A natural cut-off. Several in-flight breaking changes (e.g. > THRIFT-5956 raising PHP's minimum to 8.1) are easier to communicate as a > 1.0.0 transition than as another 0.x bump. > > > > A few questions: > > > > > - Is there a deliberate reason we are still on 0.x — a specific blocker, > or just inertia? > > - Should the next release simply be tagged 1.0.0, or do we ship 0.24.0 > first and 1.0.0 separately afterwards? > - Anything in downstream tooling that would break with a major-version > jump? > > Thanks, > > > Volodymyr Panivko >
