There are some step to prepare plugin for API update.

Some update can be done stay compatible with old LimeSurvey, some not.


I don't test whole (in all version of LimeSurvey), but can be interesting for other plugin dev.


1: extend of class name : usage of For plugin in 2.05 : it's the way to go. In future version : we can not use PluginBase directly , then must update to Think solution must work with all LimeSurvey version

2: constructor For plugin in 2.05 : it's the way to go, in future version, must use init function. BUT : init solution was added during 2.05 developement phase (don't remind the build number), then alterantive solution can be (not tested).
Alternative solutuion : use
Adding this 2 lines at start of your class:
If someone have time to test this solution with 1st 2.05 and 2.63.0 : it can be great

DenisChenu wrote: 1st 2.05 and 2.63.0 : it can be great

What is 2.05? Is that a API version or a LS version?
If it is a LS version the confusion is that the current LTS version is called 2.6.X.
Referencing to 2.05 will add confusion if LTS is meant.

From just following the forum I wonder if any thread brought attention to a API update pending.
Since you're spending extra time doing this, I just wonder about the silence from LS GmbH about these things.

jelo wrote: What is 2.05? Is that a API version or a LS version?
If it is a LS version the confusion is that the current LTS version is called 2.6.X.

I already answer : it's 2.05, not 2.6lts.

2.6 lts are ready (have init function ready), 1st 2.06 are ready (have init too).

I didn' test with the 1st 2.05 version (and some of our user have 2.05 version)

API update must be done in 3.0/develop version only, since LimeSurvey use Semantic Versioning 2.0.0 ( semver.org/ ) versdionning : all API broker must be done ONLY for major release.

It's not the case between (2.05|2.06.2.6lts) to 2.50.0, but i HOPE it can be the case after 3.0.0

DenisChenu wrote: I already answer : it's 2.05, not 2.6lts.

Thanks for pointing it out to me.

But this versioning of LS is so confusing. Even I still don't know 100% what is what.

2.05
2.06lts
2.6lts
2.5x
2.6x
...

I really think it was an unnecessary move to rename the 2.0x branch to 2.x... totally confusing for "normal" users. But who needs users, right?

holch wrote: I really think it was an unnecessary move to rename the 2.0x branch to 2.x... totally confusing for "normal" users. But who needs users, right?

+1

+1 but more :

Updating API protocol with same number ( 2.05 at start have not same API than 2.05 at end).

But it's an old issue, now it's semver and we try to respect API (here the 2.63.1 revert the broken API part).

The : now
1. If you have a template or a plugin or an external system (using RPC) (without bad hack)
2. If in a release YOUR system was broken
3. Report the bug : broke the API => update major version

What is API
- For plugin : you use $this or $this->getEvent : it's in API. You use Yii::app() : you go out of API (but move to Yii 2 is surely a new major version too, then : you follow API of Yii)
- For RPC : usage of function : your function work with such parameters in such order : if LS core update order (for example) => it's a major version
- For template : it's more unclear , but without workaround : you follow API.

Remind : my Point Of View, i didn't (and never) talk for LimeSurvey.

Denis

holch wrote: I really think it was an unnecessary move to rename the 2.0x branch to 2.x... totally confusing for "normal" users. But who needs users, right?

LS GmbH is looking for customers, not users. Customers are users which are paying for something.

The change is OK, but the usage in the forum needs to be stringent.
Version X.Y.Z

Version 2.6 is the same as 2.06 since 6 and 06 is the same value.
So if you mean 2.50 you cannot write 2.5 as we all have done in the past.
5 ist not 50.

X.50.Z is NOT the same as X.5.Z
X.05.Z is the same as X.5.Z

The comfortupdater is showing them like this:
2.6.4-lts (170202) (stable)
2.63.1 (170305) (stable)

The LTS suffix will ease confusion about version schema.
As long as -lts is added it should be no longer a big issue. LS 3.Y.Z will solve that issue completely.
We hopefully won't see a 2.63.Z LTS.

DenisChenu wrote: Remind : my Point Of View, i didn't (and never) talk for LimeSurvey.

No need to say it is your POV. Currently the LimeSurvey OpenSource Project is 100% steered by and depended on the business decisions of LimeSurvey GmbH. Hopefully we won't get into a Mambo/Joomla situation.

I thought a API versioning should be complete independent from the LS version.

Is a move to Yii 2 planned? Never read anything about Yii 2 related to LS.

jelo wrote: ....
I thought a API versioning should be complete independent from the LS version.
...

You can't really, else you have to leave some buggy code and hard to maintain code.

semver allow this : majopr version potentially broke API.

Same for Android : a tool done for android 4 can break in Android 7. You want to leave android unmodified ?

DenisChenu wrote: You can't really, else you have to leave some buggy code and hard to maintain code.

Buggy and hard to maintain code is the norm.
Or in other word: "It’s not just irreducible complexity; it’s unknown complexity." from "Features are faults"
www.tedunangst.com/flak/post/features-are-faults

There is no HOPE.

jelo wrote: Never read anything about Yii 2 related to LS.

bit.ly/2l855EV