MyBB 1.9 hakkında bilinenler

Rapid

Admin
Yönetici
Admin
Moderatör
Katılım
7 May 2015
Mesajlar
2,852
Tepkime puanı
14
MyBB 1.9 hakkında bilinenler bilgiler (geliştiricilerin verdiği bilgilerden derlenmiştir.)


- Geliştiriciler 1.8 versiyonunda artık şablon eklemek istemediklerini belirtiyorlar, yani bundan sonra gelecek gelişmeler güncellemeler sadece güvenlik ve kararlılık üzerine olacak.
- MyBB 1.9 PHP 7.3 ve üstü sürümlerde çalışacak. (ek bilgi: Ayrıca ilerleyen güncellemelerle mybb 1.8'i PHP 8.0 versiyonuna uyarlamak için çalışmalar yapıyorlar.)
- MyBB 1.9 Mobil uyumlu bir tema ile gelecek ve 1.9 çıkacak temalar doğal olarak mobil uyumlu şekilde gelecek.
- Şablon Sistemini twig ile birlikte değiştirme kararındalar. Yani bazı şeyleri yapmak için artık ek bir şablon ya da eklentiye gerek kalmayacak. (Twig, PHP için modern bir şablon motorudur).
- MyBB 1.9 sisteminin şablonları tamamen bitmiş olsa da, hala versiyonlar arasındaki senkronizasyonu sağlamaya çalışıyor. Bu elbette tamamen yükseltme sistemi için önemli.
- Bu versiyon ile birlikte, kullanıcıların şifrelerini daha güçlü bir sistem ile şifrelemeyi düşünüyorlar, md5 şifrelemesinin zayıf kaldığına inanıyorlar.
- Shiftmailer kütüphanesini kullanmaya başladılar, bu da bazı SMTP sunucuları arasındaki posta gönderme sorununu ortadan kaldıracak.
- Ayrıca 1.9'dan sonra sürümler 1.10.0, 1.11.0, 1.12.0 olarak gidecek ve 2.0 sürümüne kadar kararlı hale getirilecek. Alt yapı çalışmaları mutlaka olacaktır.

Ayrıca size planlarınıda bırakıyorum:


Euan T. :

Okay, so how about this as a roadmap for the future:
  • Plan for a 1.9.0 release as the next major release. This release would:
    • Bump required PHP vesion to PHP 7.0 in anticipation for the future. [DONE]
    • Implement Twig as a template engine. [IN-PROGRESS]
    • Introduce Composer to manage 3rd party dependencies and provide autoloading [DONE]
    • Introduce the SwiftMailer library to handle the sending of emails, fixing compatibiltiy issues with different SMTP hosts. [DONE]
    • Introduce a brand new theme which would be fully responsive and mobile ready. [IN-PROGRESS]
  • Once 1.9.0 is released, work towards the next major version as 1.10.0. This release would:
    • Introduce user alerts to the core, alerting users of new PMs, replies to threads, etc.
    • Look at introducing other 3rd party components (such as introducing a third party caching library to add more cache drivers, introducing a new query builder to be used whenever new features are added or reworked).
  • Once 1.10.0 is released, work towards the next major vesion as 1.11.0. This release would:
    • Bring in conversations as a replacement for Private Messages, and integrate them with the alerts system from 1.10.0.
    • Continue introducing other 3rd party components.
  • Once 1.11.0 is released, work towards the next major vesion as 1.12.0. This release would:
    • Look at changing the plugin structure to make use of Composer and provide plugins as Composer packages. This would:
      • Allow plugins to easily register classes in the autoloader
      • Make it easier for plugins to add new JS, CSS, etc. as plugins would all extend a base class that would provide common funcitonality - much like the 3rd party PluginLibrary project by frostschutz does
      • Make it possible in the future to automate the installation of plugins straight from the Admin Control Panel, as all plugins would follow a common structure.
    • Continue introducing other 3rd party components.

In the background, as this process happens, we could continuously work on larger refinements and enhancements such as adding a CLI tool to the core, rewriting the ACP to make use of templates, etc. These major additions and changes could be rolled into the next major release (where the middle version changes, such as 1.8 -> 1.9 or 1.9 -> 1.10).

Also of note for this approach is a slight change to how we number versions. Currently, we skip odd numbers and call them development versions. This is pretty odd, and makes little sense when the numbers don't actually get used anywhere in the core. With this roadmap we'd be using verison numbers in a way that makes more sense.

Any more thoughts or comments on the above approach? I'd rather the whole community were settled on an approach and knew where MyBB as a project is heading.

If the majority of us agree with a roadmap like the above (or one based upon this kind of structure with a clear plan of tasks to complete - we are open to changes, so long as it doesn't become a case of the plan being entirely impossible to achieve with 1001 features being added every release), I will write a blog post and start a project (or series of projects - one per version number for the next 2-3 major verisons) on GitHub to get momentum heading in that direction. What I don't want is for us to agree on a roadmap or plan and then have to change direction once again because people have found something else to be unhappy about.
 
Üst