 |
Seb Wizard
Joined: 14 Aug 2004 Posts: 1269
|
Posted: Wed Nov 14, 2007 1:11 am
[2.11] Package Library suggestion: Add min & max compatible CMUD versions |
This is a suggestion for the Package Library. With the advent of incompatible changes and new features since CMUD 1.0, I reckon we are going to need minimum and maximum compatible CMUD versions added as fields in the database. Then authors can put the minimum and maximum version of CMUD that they think their package will run on. Much like Firefox extensions, with the difference that people would still be able to install packages marked as incompatible. Minimum should default to 1.0 and maximum defaulting to the major version with which the package was uploaded plus .99 as the minor version. So if I uploaded a package with 2.11, the defaults would be 1.0 and 2.99. If I knew that I was using new style functions I'd put the minimum to 2.0. If I was relying on #BREAK or something else added in 2.12, I'd put 2.12. For searching the package library, the most user friendly is probably to add a checkbox (not enabled by default) to only show compatible packages, with perhaps options to filter by minimum and maximum version number too.
There is something called installedversion I see in the advanced filter bar, but it doesn't seem to work, is not really sufficient, and not very user friendly. |
|
|
 |
Fang Xianfu GURU

Joined: 26 Jan 2004 Posts: 5155 Location: United Kingdom
|
Posted: Wed Nov 14, 2007 10:30 am |
This has been suggested a couple of times, and I think it's on the wishlist. Anyway: hear, hear!
|
|
|
 |
Iceclaw Apprentice
Joined: 11 Sep 2005 Posts: 124
|
Posted: Wed Nov 14, 2007 1:07 pm |
Seconded.
|
|
|
 |
Zugg MASTER

Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
|
Posted: Wed Nov 14, 2007 6:12 pm |
Yep, this is on the wish list already. Hopefully soon because it's going to be important to know that a package requires 2.x and doesn't work in 1.34.
|
|
|
 |
Rorso Wizard
Joined: 14 Oct 2000 Posts: 1368
|
Posted: Wed Nov 14, 2007 6:43 pm |
Zugg wrote: |
Yep, this is on the wish list already. Hopefully soon because it's going to be important to know that a package requires 2.x and doesn't work in 1.34. |
A solution that could fix a large part of the problem would be if the zScript engine was in its own separate .dll file. Then cMUD could automatically download the latest .dll-file so even if you use an old version of the client you would be able to run most of the new scripts. |
|
|
 |
Zugg MASTER

Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
|
Posted: Wed Nov 14, 2007 6:50 pm |
Sorry Rorso, that will *never* happen. zScript is too intertwined with the rest of CMUD, and it would just cause an unnecessary drop in performance from the DLL calls and Windows context switches. Also, new zScript features are also accompanied by other changes to CMUD to support those features (various preferences, etc), so you wouldn't ever just be able to load a new zScript DLL into an older version and expect it to work. Sorry, but CMUD just wasn't designed that way.
And, as we all know, multiple DLLs really still doesn't solve these issues. Just look at the "DLL hell" that we have with Windows, getting different versions of COMCTL32.DLL, etc. You'd still need to put some information into the Package Library to tell what min/max DLL version was needed for a package, and then you'd have the problem of dealing with multiple packages that needed different DLL versions. A lot of work without actually solving the problem. |
|
|
 |
Tech GURU

Joined: 18 Oct 2000 Posts: 2733 Location: Atlanta, USA
|
Posted: Wed Nov 14, 2007 6:54 pm |
There's problems with that though. Unless you have it dependent on upgrades cycle then you can possibly get new code features if you haven't upgraded. What's worse you can start having problems in the package because you could potentially have no UI for some settings or the may change the behavior of CMUD erratically unless you have the full code.
|
|
_________________ Asati di tempari! |
|
|
 |
Rorso Wizard
Joined: 14 Oct 2000 Posts: 1368
|
Posted: Wed Nov 14, 2007 7:09 pm |
Tech wrote: |
There's problems with that though. Unless you have it dependent on upgrades cycle then you can possibly get new code features if you haven't upgraded.
|
That was the intention with the suggestion. That everyone would have same basic scripting engine even if they haven't upgraded. |
|
|
 |
Zugg MASTER

Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
|
Posted: Wed Nov 14, 2007 7:28 pm |
Then it's even worse...paid upgrades are the only way I'm staying in business in the future, so I certainly don't want any way for people to use new features without getting the new versions.
In any case, let's not hijack the original topic. The DLL thing is never going to happen, so it's a waste of time to talk about it. Let's stay focused on the current beta and what it needs, and it does need the Min/Max versions in the package library as Seb originally posted. |
|
|
 |
|
|