Hi mingcheng, > crates is currently 0.67, which doesn't seem very “mature,” so I'd > suggest moving it to 1.0 when into the podling stage - that way looks > more "mature" and production-ready :-)
Thanks for your feedback :D A 1.0 release would typically associate with a stable promise. I'm going to release a 0.7 version this month to include several breaking changes and module structure rearrangement, and see if the state is in a good shape for 1.0. That said, I'm a big fan of providing stable APIs that downstream projects can rely on. But the version series should reflect the real stable status, or else it would be meaning less. For example, a project release 100.0.1 months after its 1.0.0 release, has noting different from staying in 0.x. Here is a meme site about ZeroVer [1] and you would find several ASF (top-level) projects on list :D [1] https://0ver.org/ Back to Asyncband, the scope has been discussed as: * Asynchronous primitives like Semaphore, Mutex, WaitGroup, Latch, etc. * Composited utilities like shutdown. * Channels with multiple strategies. * Concurrency control like admission, singleflight, and perhaps something like select!/join! later. Non-goals contain: * IO reactor/proactor (fs, net, signal, timer, ...). We can continue incubating that at fast/scorpio. * Schedulers (tokio's scheduler, yatp, etc.). I have no idea about working on these, yet. * Future/Stream combinators. It is covered by rust-lang/futures and actually with full async/await support this should be unnecessary. It's actually a big challenge to provide stable API promises. Or we can keep the stable one documented while other stay behind an "unstable-<feature-name>" feature flag. All of that are technical details we can work together :D Best, tison. mingcheng <[email protected]> 于2026年8月13日周四 21:52写道： > Hi, tison > > Thanks for driving this work forward so efficiently. > > Here is one more small suggestion: I see the asyncband version on > crates is currently 0.67, which doesn't seem very “mature,” so I'd > suggest moving it to 1.0 when into the podling stage - that way looks > more "mature" and production-ready :-) > > > On Thu, Aug 13, 2026 at 8:52 PM tison <[email protected]> wrote: > > > > The rebrand has been done: > > > > * https://github.com/fast/asyncband > > * https://crates.io/crates/asyncband > > > > The PODLINGNAMESEARCH ticket has been filed: > > > > * https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-257 > > > > Best, > > tison. > > > > > > Xuanwo <[email protected]> 于2026年8月12日周三 23:30写道： > > > > > Thank you for raising this! > > > > > > Learnt a lot about mea. I'm happy with the new name. > > > > > > On Wed, Aug 12, 2026, at 20:28, Twice wrote: > > > > Hi IPMC, > > > > > > > > I would like to propose Asyncband [1] as a new Apache Incubator > > > > project, you can find the proposal of Asyncband [2] for more details. > > > > > > > > The project was previously named MEA and was discussed in an > Incubator > > > > thread [3]. Based on community feedback, we decided to rename the > > > > project Asyncband because MEA was too short and could be ambiguous in > > > > some languages. > > > > > > > > I'm acting as the champion, and we currently have 4 mentors > (including > > > me). > > > > > > > > Full proposal inlined below for easy reading. > > > > > > > > [1] https://github.com/fast/mea > > > > [2] > > > > > > > > https://cwiki.apache.org/confluence/spaces/INCUBATOR/pages/446071349/Asyncband+Proposal > > > > [3] https://lists.apache.org/thread/5pb2rtzjmn1rzchfglokslgwwg293o47 > > > > > > > > Best regards, > > > > Twice > > > > > > > > > ------------------------------------------------------------------------- > > > > > > > > Abstract > > > > Asyncband is a runtime-agnostic Rust library of composable > > > > synchronization, coordination, channel, and concurrency-control > > > > primitives for asynchronous applications. > > > > > > > > Proposal > > > > Asyncband provides reusable building blocks for asynchronous Rust > > > > programs without coupling applications or libraries to a particular > > > > async runtime. Its primitives interoperate through Rust’s standard > > > > Future, Context, and Waker interfaces and can therefore be used with > > > > Tokio, async-std, or other executors. > > > > > > > > The proposed project scope includes: > > > > - Synchronization primitives such as Mutex, RwLock, Semaphore, > > > > Barrier, Condvar, Latch, WaitGroup, Once, OnceCell, and OnceMap. > > > > - Communication primitives such as one-shot, bounded and unbounded > > > > MPSC, and broadcast channels with different delivery and overflow > > > > strategies. > > > > - Composed coordination utilities such as graceful shutdown > signaling. > > > > - Concurrency-control utilities such as admission control and > > > > duplicate-call suppression. > > > > The following areas are intentionally outside the project’s scope: > > > > - I/O reactors or proactors for filesystems, networking, signals, > > > > timers, or similar facilities. > > > > - Task schedulers or complete async runtimes. > > > > - General-purpose Future or Stream combinator libraries already > > > > covered by the Rust futures ecosystem. > > > > Asyncband is intended to be a focused, commons-style foundation for > > > > async synchronization and coordination in Rust rather than another > > > > async runtime. > > > > > > > > Background > > > > Asyncband was started by Zili Chen (tison) in October 2024 and has > > > > been developed publicly on GitHub under the Apache License, Version > > > > 2.0. The project was previously named MEA and publishes the mea crate > > > > on crates.io and versioned API documentation on docs.rs. Right now, > we > > > > have four active contributors and the crate has been downloaded more > > > > than 5M times. > > > > > > > > Rationale > > > > Async Rust libraries frequently need synchronization and coordination > > > > facilities even when they do not want to impose a particular runtime > > > > on downstream applications. Runtime-specific primitive > implementations > > > > can introduce otherwise unnecessary coupling, while repeatedly > > > > implementing low-level concurrency machinery increases correctness > and > > > > maintenance risks. > > > > > > > > Asyncband addresses this gap with a coherent set of > > > > executor-independent primitives and a deliberately small runtime > > > > dependency surface. It gives libraries a shared implementation for > > > > common concurrency behavior while allowing applications to choose > > > > their executor. > > > > > > > > Moving Asyncband to the ASF would establish durable, vendor-neutral > > > > ownership and a transparent, merit-based governance model. It would > > > > also create a neutral place for users of different runtimes and > > > > downstream projects to collaborate on correctness, API design, > > > > performance, documentation, and new primitives within a well-defined > > > > scope. > > > > > > > > Initial Goals > > > > By transferring ownership of the project to the ASF, Asyncband > expects > > > > to ensure its neutrality and further encourage and facilitate the > > > > adoption of Asyncband by the community. > > > > > > > > Some of the areas we would like to focus on during the Apache > > > > incubation phase include: > > > > - A healthier community: More contributors could be able to > > > > participate in Asyncband and own different modules. > > > > - Wider adoption: Asyncband can be adopted by more Rust projects, > > > > which in turn drives its own functionality. > > > > - Strengthening correctness evidence through cross-runtime > integration > > > > tests, stress and property testing, and targeted model checking. > > > > - Establishing reproducible benchmarks and improving performance > > > > without compromising safety, fairness, or API clarity. > > > > > > > > Current Status > > > > Meritocracy > > > > Asyncband has been developed through public GitHub issues and pull > > > > requests. Contributors receive credit through the repository history > > > > and release notes, but project ownership and release authority are > > > > currently concentrated in the founding maintainer, and no formal > > > > committer-governance model exists yet. > > > > > > > > The initial community intends to adopt the Apache Way. Technical and > > > > governance decisions will be made transparently on ASF-managed > > > > channels, contributions of code and non-code work will be evaluated > on > > > > merit, and contributors who demonstrate sustained positive > > > > participation will be invited to become committers and PPMC members. > > > > > > > > Community > > > > Contributors: 9 > > > > > > > > Users: > > > > - Apache OpenDAL > > > > - Prek > > > > - Foyer > > > > - ScopeDB > > > > - ... and more on https://crates.io/crates/mea/reverse_dependencies > > > > The donation discussion is public at > > > https://github.com/fast/mea/issues/140. > > > > > > > > Core Developers > > > > The current core developers have experience with Rust, asynchronous > > > > systems, and public open-source collaboration. Zili Chen is an ASF > > > > Member and IPMC member with experience mentoring incubating projects. > > > > Yunze Xu is an Apache Pulsar PMC member. Dian Luo and Haixu Ouyang > > > > have contributed to the implementation, documentation, testing, and > > > > maintenance of Asyncband and related projects in the fast GitHub > > > > organization. > > > > > > > > This gives the initial group some ASF experience, but not every core > > > > developer is familiar with ASF release, governance, and communication > > > > practices. The Mentors will help the whole community learn and > > > > consistently apply those practices. > > > > > > > > Alignment > > > > Asyncband is already licensed under Apache-2.0, is developed in > > > > public, and is directly used by Apache OpenDAL. Its purpose as > > > > reusable, vendor-neutral infrastructure aligns with the ASF’s > emphasis > > > > on community-led development and long-term stewardship. > > > > > > > > The ASF hosts a growing set of Rust projects and Rust components, > > > > including Apache OpenDAL, Apache DataFusion, and parts of Apache > > > > Arrow. Asyncband can provide shared async coordination infrastructure > > > > for Apache projects where appropriate while remaining useful to the > > > > wider Rust community. > > > > > > > > Known Risks > > > > Project Name > > > > This project was previously named MEA, which stands for “Modular > > > > Essentials for Async”. During previous discussions at the Apache > > > > Incubator, we realized that MEA might be too short and ambiguous in > > > > some languages, so it was renamed Asyncband. > > > > > > > > Orphan Products > > > > Asyncband is a small library whose maintenance has so far been led > > > > primarily by one person, so loss of interest by the founding > > > > maintainer is a real risk. Existing downstream adoption and the > > > > commitment of four active contributors reduce the immediate risk, but > > > > they do not eliminate it. > > > > > > > > The central incubation goal is to distribute ownership across a > larger > > > > group of committers and downstream stakeholders. Transparent > > > > governance, documented maintenance practices, and ASF-controlled > > > > project assets will make continuation less dependent on any one > > > > individual. > > > > > > > > Inexperience with Open Source > > > > Asyncband has been developed openly on GitHub since its inception, > and > > > > all initial committers have participated in public open-source > > > > workflows. Zili Chen and Yunze Xu have substantial ASF experience, > > > > while other initial committers are newer to ASF governance, > > > > mailing-list-based decision-making, release voting, and policy > > > > requirements. > > > > > > > > The project will rely on its Mentors and experienced initial > > > > committers to teach these practices and ensure that knowledge is > > > > shared rather than concentrated. > > > > > > > > Length of Incubation > > > > Expect to enter incubation in two months and graduate in about two > years. > > > > > > > > Homogenous Developers > > > > The initial active developers are geographically concentrated in > China > > > > and share overlapping professional interests in Rust infrastructure. > > > > They are not all employed by the same organization, but the current > > > > group is still too small and homogeneous for a sustainable Apache > > > > community. > > > > > > > > The project will actively recruit contributors through downstream > > > > users, Rust runtime communities, ASF Rust projects, documentation > > > > work, testing initiatives, and well-scoped issues suitable for new > > > > participants. > > > > > > > > Reliance on Salaried Developers > > > > Asyncband is not known to depend on a development team funded by a > > > > single employer. The more significant risk is concentration of > > > > maintenance work in the founding maintainer, regardless of whether > > > > that work is salaried or voluntary. > > > > > > > > The project will mitigate this risk by sharing release, review, > > > > triage, and technical ownership among multiple committers and by > > > > recognizing sustained non-code contributions as well as code > > > > contributions. > > > > > > > > Relationships with Other Apache Products > > > > - Apache OpenDAL directly depends on Asyncband and uses it throughout > > > > its Rust implementation. > > > > - prek depends on Asyncband and is used in Apache Airflow’s > > > > development workflows, creating an indirect relationship with Apache > > > > Airflow. > > > > - Asyncband may be useful to other ASF Rust projects that need > > > > executor-independent synchronization or coordination, but no project > > > > will be expected to adopt it merely because it is hosted by the ASF. > > > > > > > > An Excessive Fascination with the Apache Brand > > > > The proposal is motivated by neutral ownership, durable > > > > infrastructure, transparent governance, and community growth rather > > > > than by endorsement or marketing value. The initial community > > > > understands that the Apache name does not guarantee adoption and that > > > > incubation requires sustained work on releases, policy compliance, > and > > > > community development. > > > > > > > > Documentation > > > > The API documentation of Asyncband is hosted at https://docs.rs/mea. > > > > > > > > If the proposal is accepted, the community may establish a project > > > > website at asyncband.apache.org; docs.rs will continue to host API > > > > documentation for published crate versions. > > > > > > > > Initial Source > > > > The project currently holds a GitHub repository and a Cargo crate: > > > > - https://github.com/fast/mea > > > > - https://crates.io/crates/mea > > > > The crate will retain its name, while the repository will be moved to > > > > the Apache org. > > > > > > > > Source and Intellectual Property Submission Plan > > > > External Dependencies > > > > The published crate currently has one direct runtime dependency: > > > > > > > > MIT > > > > slab 0.4.12 (It is planned to be removed) > > > > > > > > Cryptography > > > > N/A > > > > > > > > Required Resources > > > > Mailing Lists > > > > [email protected] > > > > [email protected] > > > > [email protected] > > > > [email protected] > > > > [email protected] > > > > Subversion Directory > > > > N/A > > > > > > > > Git Repositories > > > > From https://github.com/fast/mea > > > > - https://gitbox.apache.org/asf/repos/asyncband > > > > - https://github.com/apache/asyncband > > > > > > > > Issue Tracking > > > > The community would like to continue using GitHub Issues. > > > > > > > > Other Resources > > > > The community has already chosen GitHub Actions as continuous > > > integration tools. > > > > > > > > Initial Committers > > > > tison [[email protected]] > > > > Dian Luo [[email protected]] > > > > Yunze Xu [[email protected]] > > > > Haixu Ouyang [[email protected]] > > > > > > > > Sponsors > > > > Champion > > > > Mingyang Liu [[email protected]] > > > > > > > > Nominated Mentors > > > > tison [[email protected]] > > > > Hao Ding [[email protected]] > > > > Jean-Baptiste Onofré [[email protected]] > > > > Mingyang Liu [[email protected]] > > > > > > > > Sponsor Entity > > > > The Incubator > > > > > > -- > > > Xuanwo > > > > > > https://xuanwo.io/ > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
