Hi, tison I agree with your careful consideration regarding the project version number strategy, and I also understand that we need to be mentally prepared for the long-term maintenance of this project.
A clear plan shows that we already have many good ideas and roadmap which means a good start, I look forward to this project continuing to move forward within the incubation. At the same time, I have already started familiarizing myself with the project on GitHub. On Thu, Aug 13, 2026 at 10:01 PM tison <[email protected]> wrote: > > 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] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
