Modzzz Update?

I saw him around a while back. Have you got his e-mail?

I strongly believe that unacms management must respond since these where about questions of Jerome is harming the image of unacms and for me it is like history repeat itself.

Also, paying clients deserve support regardless of the fact that they purchased products from vendors. Vendors own the patent rights and unacms must remain with a copy of the software for issues like these.

If someone has contributed to UNA in the past but can no longer do so, I don’t see how that would negatively impact UNA. Since UNA is open source, anyone is welcome to contribute. Writing a line of code today whether it's 10 or 100, whether for free or for payment does not create an obligation to continue contributing in the future. Open source contributions are voluntary.

I believe that if you are not satisfied with a product, you should be entitled to a refund within a reasonable period. In Europe, consumer protection laws typically allow for a 15-day return window, but the specific terms depend on the conditions under which the product was purchased. Every product comes with its own set of terms and conditions that outline the rights and obligations of both the seller and the buyer.

When it comes to ongoing support and updates, I firmly believe that such services should be provided for a fee. No one can be expected to work for free indefinitely. If a product has no future development, there will be no updates, and consequently, there will be no ongoing support. In such cases, if no updates have been sold or promised as part of the initial purchase, customers cannot demand free support or improvements.

A product that was designed to function with a specific version of an operating system, software, or platform will remain functional only under those specific conditions. As technology evolves, compatibility issues may arise, and unless there is a commitment from the developer to maintain and update the product, it cannot be expected to work seamlessly in perpetuity.

However, if the product is open-source, users have the flexibility to update it themselves. They can modify the code, contribute improvements, or hire another developer if the original creator is no longer available or unwilling to continue maintaining it. This is one of the key advantages of open-source software it allows for long-term adaptability and community-driven development.

If someone worked for you today, you can't force them to work tomorrow. Everyone has the option to quit. And you can hire someone else tomorrow.

REGARDING Old code that is no longer compatible with new versions still holds value and should remain available for sale, provided it is clearly marked as such. Since these codes are open source, they can always be updated, maintaining their relevance. As long as the data is available for purchase and properly labeled, I see no reason why it should no longer be sold.

"Any disputes regarding arrangements between the Customers and Vendors of any type of products and services remain solely between Buyers and Sellers. We are not involved in any transactions between You and any other users of the UNACMS.COM web site. You acknowledge and agree that UNA Inc will not be a party to any such dispute or be obligated to take any action or refrain from taking any action toward resolving any such dispute. If you have a dispute with any other users of the Site, you hereby release UNA Inc from any and all claims, demands, and damages (actual and consequential) of every kind and nature, known and unknown, related to such a dispute." Read terms and condtion for market https://unacms.com/terms

yes, no reply

I strongly believe that unacms management must respond since these where about questions of Jerome is harming the image of unacms and for me it is like history repeat itself.

Also, paying clients deserve support regardless of the fact that they purchased products from vendors. Vendors own the patent rights and unacms must remain with a copy of the software for issues like these.

I do not share this sentiment. I've done business with Jerome for years. I don't expect them to get in yet because this has happened many times, and they step in when necessary.

Not true for modules bought

for payment does not create an obligation to continue contributing in the future. Open source contributions are voluntary.

I've been here way too long to read the terms. HAHA

I asked about someone. Everyone, please stay on topic.

thanks

If I sell you code that is compatible with the current version of UNA, I don't see why I should be obligated to provide a free update for a new version tomorrow. If I choose to sell an update, I will; if not, I won’t. If you agree to these terms, you are welcome to purchase it; if not, you are not obligated to. I provide you with open-source code today, and if you need an update in the future, you are free to hire someone else to make the necessary changes. Unless there is a contractual agreement to provide updates, you cannot demand them for free. As an example, all the products I've seen from UNA INC with updates typically require an annual subscription. If you don’t buy a subscription, you can’t expect to receive updates. If you receive a free update, that doesn't mean it's mandatory, it's just voluntary.

I've been reading Boonex's terms for about 20 years as well. But the terms comment wasn't for you.

All software products sold with a subscription for updates are eligible to receive updates anywhere on the internet. If you do not purchase a subscription for updates, I see no reason why you should receive them. Therefore, a product sold without updates will, by definition, only receive voluntary updates. However I believe that any software developer should be honest and clearly outline in the sales contract whether the product will receive future updates, ensuring transparency and avoiding any confusion. Otherwise, some customers might consider it a scam.

I welcome all comments and what a topic of interest as we revisit the terms likely to be overlooked. There is always room for improvement as we learn along the way. One important fact is how our unacms management excuse themselves from any legal agreement between vendors and clients, but at what cost?

Example:

I run my platform on open-source software which is unacms. Well, how do we define unacms open-source? it consist of the original founders together with a community divided into programmers called vendors etc. and widely spread user base relying on the broader community for support.

Now, when my site run into technical problems for example during upgrades that cause vendor product to become incompatible, how does one solve this problem, for these products were not procured outside of the unacms environment but rather internally, hoping that the overall idea between vendors and unacms management has considered all possible scenarios in particular to protect client as well as the image of unacms in the broader market, looking at reviews ect.

It is important to understand that open-source platforms like UNA CMS operate within a decentralized ecosystem. The core framework is developed by the original creators, but third-party contributors (vendors) independently build and maintain their own modules and extensions.

When upgrading a platform, it is natural that modules and components that have not been updated by their respective vendors may become incompatible. This is not the responsibility of UNA CMS itself, nor of its original creators. Instead, it falls on the vendors who develop those products to ensure compatibility, just as it is the responsibility of the client to verify whether the modules they rely on will continue to work after an upgrade.

You cannot blame the creators of the framework for the decisions or actions of third-party vendors. Just as in any open-source environment, if a vendor chooses not to update their product, users have the option to either wait for an update, find an alternative solution, or hire a developer to modify the code to restore compatibility.

Ultimately, transparency in software agreements is key. If an agreement exists between a vendor and a client, the terms should clearly state whether updates will be provided. Without such a commitment, there should be no expectation of free updates or support.

If you have purchased software from a third-party vendor, you will most likely need to pay that vendor for an upgrade. If the vendor is no longer available or chooses not to provide updates, you can always hire someone else to update the software for you. I don’t see where the problem is in that this is simply how software development and support work.

Before performing an update, you must test whether the update is possible. It is your responsibility to ensure that the third-party product is compatible with your platform, so proper testing should be conducted beforehand.

Also a third-party provider cannot predict how UNA Core will evolve, as no one can foresee future changes made by others. Therefore, updates will not always be automatically compatible. It is highly recommended to disable automatic updates and perform thorough testing on a staging site before applying any updates to your live platform.

If a third-party product is not compatible, you should contact the provider to request a paid or a free update. If the provider is no longer available, you may need to find an alternative provider in order to help you with the upgrade. Ultimately, these actions are your responsibility.

You cannot blame the UNA CMS creators for your actions/business dealings with third-party providers.

You a very interesting man Mr. Romulus...

Ever heard of it is a man made rule, or it is the order of the day?

I fully agree with you to the point of revolutionize what was once and now is... Never in my life will I like the idea of clashing with unacms management, they have changed my life in many ways and I dearly love them.

What I am saying and I did mention the terms we so easily overlook as if I was reminded how it really works.

It's time to change all this for the better... I don't ever want to sit with a perfect system having to dismantle it because the vendor has disappeared... my cry to management... change the game, keep a copy of the vendors product even though they own the patent right, just in case, for there is to much at stake here.

Another important reason to disable automatic updates is that third-party providers can only create updates for their products after the UNA Core update is released. This means that an automatic update will not be possible until they have developed and released compatible updates for their products. Therefore, any update should only be performed after testing the updates on the third-party modules. When using modules created by third-party providers, you must delay your updates accordingly, and it is your responsibility to properly manage your platform.

"Ever heard of it is a man made rule, or it is the order of the day?"

• My comments are not rules, but logical conclusions about reality.

Well said, than again... Auto updates should always work perfectly, for it is a build in feature.. the only reason I would not recommend automatic updates... should be for other reason like, we in production and not sure if the new release contain bugs... etc.

What happens behind the scenes is scary looking at the various sources of our unacms upgrade, Now this is where I agree with you for it is like that from the beginning... unacms simply release, never to know what impact it could make should things go wrong, LIKE JUST WONDERING IF OUR VENDORS ARE ON BOARD WITH OUR RELEASE I would once again ask the question... why not work inline with each other knowing what is coming... this will reduce the NUMBER of entries on our forum and clients don't have to get these surprises on their sites for things once worked and now faulty...

DO WE HAVE CONSISTANCY IN HOW THINGS ARE DONE CONSIDERING CLIENT SATISFACTION AND PUTTING THEM FIRST

You should know that there is a difference between stable update channels and/or other channels. You can't expect a UNA Core update to be stable when it is delivered through a test channel, especially when it comes to third-party modules.

Software versions are typically written in a format that includes major, minor, and patch numbers, followed by a tag indicating the development stage. Here's how the versions can be written, with examples:

Alpha (ALPHA)

The version is often tagged with -alpha to indicate that it's in the alpha stage.

• Example: 1.0.0-alpha

Beta (BETA)

For beta versions, the tag is usually -beta or -betaX (where X is the beta iteration).

• Example: 1.0.0-beta or 1.0.0-b1

Release Candidate (RC)

The release candidate is tagged with -rc and the number of the release candidate, for example, -rc1.

• Example: 1.0.0-rc1

Stable (or Final) (STABLE)

The stable version is the final release and typically doesn't have a tag, though sometimes -stable is used.

• Example: 1.0.0 or 1.0.0-stable

Maintenance (or Patch) (MAINTENANCE)

The maintenance or patch versions are typically written as -patchX or just X at the end of the version number.

• Example: 1.0.1 or 1.0.0-patch1

Long-Term Support (LTS)

LTS versions are often tagged with -lts to indicate they will receive extended support.

• Example: 1.0.0-lts

General Version Format:

Examples:

• 1.2.3-alpha
• 1.2.3-beta2
• 1.2.3-rc1
• 1.2.3
• 1.2.3-patch1
• 1.2.3-lts

This format makes it easy to identify the stage of development and the version's progress over time. While many follow the Semantic Versioning (SemVer) standard (major.minor.patch-stage), others may use different formats, such as:

• Date-Based Versions: Example: 2025.03.29 (year.month.day)
• Incremental Build Numbers: Example: 1.2.3456 (where 3456 represents a build number)
• Custom Naming: Example: Windows 11 22H2 or Ubuntu 24.04 LTS
• Internal Codes: Example: v1.0-internal-2345 (for internal builds)

Some companies may also skip version numbers (e.g., Microsoft skipped Windows 9) or use codenames (e.g., macOS "Monterey").

So, while the general concept of alpha, beta, RC, and stable applies universally, the exact notation and tagging can vary significantly depending on the company’s internal policies.