Wow, breath taking... quite useful information, The origin of this ticket has taking another toll, and opened doors for other areas of discussions like how we store information and reference it. For the first time ever, you presented the versioning and upgrades extremely well, and I believe it was there along. ( Time for a proper knowledge base apart from docs, never mind open-source)

I want to use this as an example: I clean before my door, shake my hands and I'm done following precise steps as set out in our procedures, like how it's done on an industrial manufacturing production line. But the product is far from complete, not so in your department, for your have done your bit, you done.

The above as explain by you Romulus are best practice principles and implemented for example in your github processes even, But here is the gab... una core as well as our vendors most definitely follow these steps, only if they could propose or create one final step in the overall processes, and collaborate their efforts to avoid most followed patches... that in most cases are vendors trying to catch up with the latest release, for core might have implemented a new version of the database and had to make some amendments in accordance to the new database seemingly programming requirements.

Now unacms core has to move on and have their own plans whereas vendors might be welcome to add, but on their terms and clients must understand that yes, you can purchase that product from the vendors bla bla bla .... but all creates a spaghettis system with lost of queries and entries on our forum, no to let alone that there is no SLA's, yes it open source.

I use unacms, and I once said that when taking money from my site users for services render means I am commercial now, and needs to offers my site users with some guaranties for money spend, that operations will be stable and not to worry... all I must do is yes, understand the table of content like explained by you Romulus, and prevent system failure...

Somehow sad...thanks

​For production environments, it's advisable to maintain UNA sites at a stable version. For experimental purposes, you can set up various test sites with different intermediate testing versions. For instance, while UNA's latest stable release is 13.1.0, there are newer versions like 14.0.0-RC4 currently available. However, the latest version isn't necessarily the most suitable for production; although it introduces the newest features, stability is paramount in a production setting. Therefore, it's crucial to use only stable versions in production environments and reserve testing versions for separate development sites.​

Regarding the "modzzz-update" topic, it's important to note that module developers typically update their modules in alignment with stable UNA CMS releases or apply security patches as needed. Given UNA's rapid development pace on GitHub, it would be impractical for module developers to update their modules with every core test version release. Consequently, developers like Modzzz focus on ensuring compatibility with stable core versions of UNA CMS, rather than releasing updates for alpha, beta, or release candidate test versions. This approach is practical, considering the extensive number of modules they manage and the potential for increased support inquiries. Therefore, it's reasonable for developers to prioritize updates that align with stable UNA core versions to maintain compatibility and system stability. As for me, this is how I work: I develop an application that includes submodules. First, I ensure that the core has a stable version; then, I release modules compatible with that stable core version.

I am closing off with this. You are going nowhere... I am falling in love with your thinking and analyzing facts... it's like you re-write the book of unacms and explain it to us in simple terms... love you man :-) ... talk to you soon..