تیم llama.cpp روز ۱۳ نوامبر نسخهٔ ۱.۰.۰ هم llama.cpp و هم کتابخانهٔ تنسوری زیربنایی آن، یعنی ggml، را منتشر کرد. این اعلام در یادداشتی در وبلاگ Hugging Face به قلم Daniel Bevenius، Georgi Gerganov و merve آمده است. خود شمارهٔ نسخه مهم‌تر از قولی نیست که همراهش داده شده: از این پس، به گفتهٔ این پروژه‌ها، هر تغییری که API یا رابط باینری را بشکند با افزایش شمارهٔ اصلی نسخه مشخص می‌شود تا برنامه‌های بسیاری که روی این کتابخانه‌ها ساخته شده‌اند مرزها را ببینند.
llama.cpp پیاده‌سازی C و C++ برای اجرای مدل‌های زبانی، از جمله مدل‌های چندوجهی، روی سخت‌افزاری از لپ‌تاپ‌های معمولی تا سرورهای سازمانی است و با کوانتیزاسیون و بک‌اندهای بهینه استنتاج را ارزان می‌کند. تیم می‌گوید عمر پروژه حدود سه‌سال‌ونیم است و برنامه‌های زیادی از همین حالا به آن وابسته‌اند. نسخهٔ ۱.۰.۰ دو کتابخانه را پوشش می‌دهد: libllama با سرفایل‌های عمومی در پوشهٔ include مخزن llama.cpp و libggml با سرفایل‌هایی زیر ggml/include. در GitHub هر دو مخزن در ۱۳ نوامبر برچسب v1.0.0 دارند و پیش از آن مدتی طولانی انتشارهای llama.cpp با شمارهٔ ساخت مانند b12360 عرضه می‌شدند.
یادداشت قواعد نسخه‌بندی را روشن می‌کند و این قواعد برای همهٔ پروژه‌های ggml-org که از نسخه‌بندی معنایی استفاده می‌کنند صدق می‌کند. تغییر ناسازگار در API عمومی زبان C در یک پوشهٔ include شمارهٔ اصلی را بالا می‌برد. قابلیت سازگار با گذشته، به‌روزرسانی بک‌اند، پشتیبانی از مدل تازه یا افزودن یک فراخوانی API شمارهٔ فرعی را بالا می‌برد. رفع اشکال بدون اثر بر API شمارهٔ وصله را بالا می‌برد. برای توسعه‌دهندگانی که برنامه‌شان را به libllama پیوند می‌دهند، تمایز آخر فایدهٔ عملی است: کار روی مدل‌ها و بک‌اندها، که بیشتر تغییرات در آن‌جا رخ می‌دهد، دیگر نباید در هر به‌روزرسانی بازنویسی کد را تحمیل کند.
اعلام دربارهٔ بسته‌بندی هم توضیح می‌دهد. تیم فایل‌های پیش‌انتشار برای Linux، macOS، Windows، Android و iOS، تصویرهای Docker برای Linux و بسته‌هایی از طریق Debian، Homebrew، conda-forge، MacPorts و Winget و همچنین XCFramework برای iOS و macOS را فهرست می‌کند. بسته‌بندها را به بحثی ارجاع می‌دهد که نشان می‌دهد چطور پروژه‌های ggml-org را به فرایند انتشار خود اضافه کنند؛ نشانه‌ای که تیم می‌خواهد توزیع‌های بیشتری نسخه‌های برچسب‌خورده را دنبال کنند، نه ساخت‌های پیوسته را.
دربارهٔ شیوهٔ توسعه، نویسندگان می‌نویسند که همچنان مدل‌های زبانی را در گردش‌کار خودشان به کار می‌گیرند، اما کیفیت کد، کنترل معماری و درک جزئیات پیاده‌سازی در اولویت می‌ماند. آن‌ها می‌گویند سرمایه‌گذاری بیشتری روی یکپارچه‌سازی پیوسته می‌کنند و با HF Buckets و HF Jobs از Hugging Face ظرفیت آزمون پشت هر تغییری را که به شاخه‌های master می‌رسد افزایش می‌دهند. پشتیبانی سخت‌افزاری NVIDIA، AMD، Qualcomm، Arm، IBM و Intel اجرای رانرهای خودمیزبان روی پلتفرم‌های اصلی را ممکن کرده است. به نوشتهٔ یادداشت، llama.cpp بیش از ۱۵۰ گونهٔ معماری و همهٔ روش‌های رایج رمزگشایی حدسی را پشتیبانی می‌کند و هر بک‌اند ggml را می‌توان به‌صورت کتابخانهٔ پویا ساخت و هنگام اجرا بارگذاری کرد.
این اعلام سیاست انتشار از سوی خود نگه‌دارندگان است، نه ارزیابی مستقل. یادداشت هیچ قابلیت تازه‌ای را برای ۱.۰.۰ فهرست نمی‌کند و ادعای عملکردی هم ندارد. اهمیتش سازمانی است: پروژه رابط‌های عمومی‌اش را به یک قاعدهٔ صریح سازگاری گره می‌زند و پروژه‌های وابسته این قاعده را وقتی می‌آزمایند که نسخهٔ اصلی بعدی برسد.