How to deal with incompatibilities between v8 and v9

Marketplace
#1

I have a (big) number of packages in the MP running on v8. They will not work on v9 and it will take me years to upgrade them to run on both v8 and v9 because of the core versions backward incompatibility. It’s not worth the effort.

So from the MP point of view, if I upgrade a package run its next rev on v9 but not on v8, should I put a note saying something like v1.2.3 was the last one compatible with v8 and will not run on v9 and v4.5.6 is the first compatible with v9 but will not run on v8?

How do I prevent refunds in case they don’t see the note? Do the MP rules cover for that?

1 Like
#2

Consider the two broad approaches to v9 compatibility.

  1. A new package version that works in both v8 and v9
  2. A new package version specific to v9, with a separate version for v8

Now consider the two v9 scenarios
(A). A fresh site in v9, packages are then added
(B). A site updated to v9 from v8, packages are already installed in v8.

With (A), it doesn’t matter which of (1) or (2) is adopted for making a package compatible. Either approach will work with a fresh install to v9.

With (B), package approach (1) should always work.

But approach (2) can get into a chicken and egg problem. A v9 version of the package cannot be installed to a v8 site. Yet when the site is updated, the package remains v8 and is incompatible with v9. If the incompatibility is minor, then the next action is to go to the dashboard and update the package to the v9 compatible version and all will be OK. However, if the v8 version of the package breaks the site sufficiently that the dashboard/upgrade is inaccessible, the site is now broken unless the package can be upgraded to its v9 compatible version manually.

Hence achieving (1) is by far the preferred solution. As a backstop, if I can’t achieve (1) and need to resort to (2), I will at least create a new v8 version of a package that won’t break a v9 site too badly, so allowing an update to the v9 version of the package after the site is updated to v9.

#3

Hi @JohntheFish !

What you’re saying from the technical point of view is all good. Sorry if I can’t get my thoughts across. I am asking from a commercial/legal/license point of view. What I am wondering about is this. Say,

  • there a package on the Market Place version 1.0 done for v8, works 100% in v8, doesn’t work in v9 at all, it’s not even meant to work in v9
  • someone purchases that package (what’s stopping them?), installs it, break the site or it looks as ugly as hell because of Bootstrap and decides it’s f***ed and wants a refund
  1. So what protection do I have in that case? What’s stopping them from purchasing 10, 100 packages and then asking for refunds? That basically letting them to get the packages for free.
  2. If I put a note on the package MP page saying the last version guaranteed to work in v8 is v1.0, no guarantee/support/refund offered for purchasing that version and installing it on v9. Can I do that? Will Concrete be on my side in case they ask for a refund anyway?
  3. If I do upgrade my package for v9 but I don’t want to maintain compatibility with v8, do I just release another version under the same package handle or do I have to make a completely new package and submit it to the MP which will be v9 compatible?
  4. If I do upgrade my package for v9 but I don’t want to maintain compatibility with v8 and I just rev it up, can I put a note on the package MP page saying the first version guaranteed to work in v9 is v2.0, no guarantee/support/refund offered for purchasing any lower version and installing it on v8. Can I do that? Will Concrete be on my side in case they ask for a refund anyway?
#4

I share your concerns. That is why we need a maximum version compatibility built into the marketplace, core and packages. We need interlocks in place to save site owners from making such mistakes.

  1. There have been chancers who do such with the current marketplace and hold developers to ransome with the threat of a bad review if they don’t get a refund. Report it to @frz and they will get blocked. Any blackmail reviews they leave can be deleted.
  2. The existing marketplace license already states that refunds are not entitled when an addon does what it says it does. However, v8 to v9 is something that could easily be overlooked by buyers and whilst declining to refund may be justified, it doesn’t do anything for our reputations as developers or for Concrete CMS as a whole. Hence we need mechanisms in place to prevent such.
  3. You can do either. The mechanisms already exist in the marketplace for mapping addon versions to core versions within the same marketplace item. They are just a faff to use and could do with some thought about better usability.
  4. As per 2. Relying on such a statement whether supported by @frz or not would ruin your reputation as a developer and be bad for the reputation of Concrete CMS as a whole.