Stable olarak sunulan bir projede release süreci ve temel sorunlar

[MehmetAliPolat1515]

Stable olarak sunulan bir projede release süreci ve temel sorunlar

Bunu kişisel bir saldırı olarak değil, Perry'yi gerçek bir projede kullanmaya çalışırken yaşadığım deneyime ilişkin eleştirel bir kullanıcı geri bildirimi olarak yazıyorum.

Perry'nin büyük ölçüde tek kişi tarafından geliştirilmesi ve derleyici geliştirmenin zor olduğu iddiasını, duruma göre bazı gecikmeler açısından kabul edilebilir bir açıklama olarak görebilirim. Ancak bunun her problemi otomatik olarak mazur gösterdiğini düşünmüyorum.

Özellikle Perry'nin resmi sitesinde Linux / GTK4 ve Web / JavaScript hedefleri Stable olarak sunuluyor.

Karşılaştığım iki temel sorun:

• #8587 — Native Linux perry/ui linking failure
• #8584 — Web TextField returns NaN instead of the entered string

#8587'de v0.5.1220 ile kod derlenip object file oluşturulmasına rağmen final linking başarısız oluyor ve executable üretilemiyor. Linking gibi temel bir işlem çalışmadığında projeyle ilerleme şansı fiilen kalmıyor.

#8584'te ise Web hedefindeki temel bir TextField, beklenen string yerine NaN / number döndürüyor. Aynı kod Linux / GTK4 üzerinde doğru çalışıyor.

Benim eleştirim hata çıkması değil.

Yazılımda hata çıkabilir. Fakat Stable olarak sunulan hedeflerde bu kadar temel sorunların kullanıcıyı tamamen bloke etmesi ve sorun giderilip issue kapatıldıktan sonra düzeltmenin günler boyunca kullanılabilir bir release'e ulaşmaması bence ciddi bir problemdir.

Her iki issue da 22 Ağustos 2026'da bildirildi ve şu anda kapalı. Buna rağmen GitHub'daki Latest release hâlâ 4 Temmuz 2026 tarihli v0.5.1220.

Bir kullanıcı açısından düzeltmenin main branch'te bulunması yeterli değildir.

Düzeltmeyi normal kurulum yoluyla kullanamıyorsam, sorun benim açımdan hâlâ çözülmemiştir.

Blocker seviyesindeki bir sorun için en azından hızlı bir patch release, net bir release planı veya kısa bir durum açıklaması beklerdim.

Perry'nin tek kişi tarafından yürütülmesi belirli şartlarda gecikmeleri açıklayabilir. Ancak kişisel olarak derleyici yazmanın, bu seviyedeki temel release ve kullanılabilirlik problemlerini tek başına mazur gösterecek kadar olağanüstü zor bir eylem olduğuna inanmıyorum.

Üstelik günümüzde yapay zekânın kod analizi, debugging, test, CI/CD ve release süreçlerinde sağladığı imkan ve rahatlık düşünüldüğünde, zaten giderilmiş blocker seviyesindeki sorunların günler boyunca release edilmemesini çok makul karşılamıyorum.

"Proje büyük", "tek kişi geliştiriyor" veya "derleyici geliştirmek zor" gibi açıklamalar durumu açıklayabilir; fakat bence otomatik olarak haklı çıkarmamalıdır.

Stable ifadesinin bir karşılığı olmalı.

Kullanıcı en azından:

1. Temel işlevlerin çalışacağına,
2. ilerlemeyi tamamen durduran regression'ların öncelikli ele alınacağına,
3. düzeltmelerin makul sürede release edileceğine,
4. gecikme varsa bunun açıkça belirtileceğine

güvenebilmelidir.

Şu anki deneyimim maalesef bu güveni vermiyor.

Bence Perry'nin yeni özellikler ve performans kadar release güvenilirliği, blocker seviyesindeki sorunların yönetimi ve kullanıcı iletişimine da önem vermesi gerekiyor.

---

Release process and fundamental issues in a project presented as Stable

I am writing this not as a personal attack, but as critical user feedback based on my experience trying to use Perry in a real project.

I can consider the fact that Perry is largely developed by one person, and the claim that compiler development is difficult, an acceptable explanation for some delays depending on the circumstances. However, I do not think this automatically excuses every problem.

This is especially relevant because Perry's official website presents the Linux / GTK4 and Web / JavaScript targets as Stable.

The two fundamental issues I encountered are:

• #8587 — Native Linux perry/ui linking failure
• #8584 — Web TextField returns NaN instead of the entered string

In #8587, with v0.5.1220, the code compiles and an object file is generated, but final linking fails and no executable is produced. When something as fundamental as linking does not work, there is effectively no way to continue using the project.

In #8584, a basic Web TextField returns NaN / number instead of the expected string, while the same code works correctly on Linux / GTK4.

My criticism is not that software defects can occur.

Problems can happen in any software project. However, I consider it a serious issue when fundamental failures completely block users on targets presented as Stable, and the fixes remain unavailable through a usable release for days after the issues have been addressed and closed.

Both issues were reported on August 22, 2026 and are currently closed. Yet the Latest GitHub release is still v0.5.1220, released on July 4, 2026.

From a user's perspective, having the fix on main is not enough.

If I cannot install and use the fix through the normal release channel, the problem is still unresolved for me.

For a blocker-level issue, I would expect at least a quick patch release, a clear release plan, or a short status update.

The fact that Perry is maintained by one person may explain some delays under certain circumstances. However, personally, I do not believe that writing a compiler is such an extraordinarily difficult activity that it alone excuses this level of fundamental release and usability problems.

Moreover, considering the capabilities and convenience that AI now provides for code analysis, debugging, testing, CI/CD, and release processes, I do not find it very reasonable for already-resolved blocker-level issues to remain unreleased for days.

"The project is large", "it is maintained by one person", or "compiler development is difficult" may explain the situation, but in my view they should not automatically justify it.

The Stable label should mean something.

Users should at least be able to trust that:

1. Fundamental functionality works,
2. regressions that completely block progress are treated as a priority,
3. fixes reach releases within a reasonable amount of time,
4. and delays are communicated clearly.

Unfortunately, my current experience does not provide that confidence.

I think Perry needs to place more emphasis on release reliability, handling of blocker-level issues, and user communication, alongside new features and performance.