The section of this mod is qualified for SMF 2.0 through 2.0 Beta 4 and 2.0 RC2. I'm pretty sure RC2 is a later SMF version. Would the following be correct to allow 2.0 through both Beta 4 and RC2?
<install for="2.0 - 2.0 RC2">
I just want to be certain that range includes Beta 4. It's not that I expect anybody to install the mod on any of those ranges, but I want to cover the possibility that somebody might want to uninstall my mod and are currently running one of those releases and didn't save the mod package.
It's just a downwards compatibility issue. I don't want to leave anybody high and dry.
The following will cover 2.0 Beta 4, 2.0 RC1, 2.0 RC1-1 and 2.0 RC2 only:
<install for="2.0 Beta 4 - 2.0 RC2">
Is there any way to include 2.0 in that?
I'd suggest just dropping the beta and RC notations and just use
install for 2.0 - 2.99
anyone who is still using a beta or RC version should be put out of their misery because their site is a potential disaster waiting to happen
Thanks Kin, but 2.0.6 has changes vs. RC2 that make the mod incompatible with the whole "2" family.
I guess probably the best bet is to just leave the in old install/uninstall XML and add a new one for 2.0.6-2.0.7 or maybe even 2.0.6-2.99.99.
It's a good thing I did that to some of my mods, particularly the SMF 1.x mods. It turned out 1.x has been pretty stable, probably just bug fixes and security patches for years. I'm thinking like particularly Anti-Spam Verification Questions for SMF 1.1.x (http://custom.simplemachines.org/mods/index.php?mod=1516) which merely ported the SMF 2 anti-spam questions to 1.x because back around the original release date we were having major spammer invasions and I felt sorry for the folks running 1.x. The spammers were killing them! That mod is unlocked for any 1.x version.
I don't know how soon 1.x is going end of life but I'm betting that mod will work with SMF 1.x forever.
I already know that many of my mods will not be compatible with SMF 2.1 if what I hear is correct. Remembering from what I heard years ago there will be major template changes so it's unlikely any of my mods will go unscathed.
I feel good though. I got 5-6 mods updated today so I'm about 20% towards my goal of making all my mod packages once again available to the SMF community. I have a few to do tomorrow that are based on the ones I did today so they too will be mere reformatting, probably less than an hour each.
With the compatible mods it's mostly just updating the read-me files to update the copyright notice and put my present contact email address in the source code, and removing the carriage returns from the source code. The package installer ignores carriage returns anyway but I like to have all my code files pristine.
I'm pleased that I had anticipated several weeks labor to update all my 25 mod packages but it looks like I may have most of them updated in less than a week. (Unfortunately Look But No Read is not only one of the most requested but probably also the last, due to security issues, and will have to be requalified by the Mod Team.)
I can't wait to get to my new mod package ideas. Over the last several years I've written my own custom content delivery system (CDS) that allows me to host multiple websites using the same code. Just like SMF it's database driven so the same code works on all my sites. (In fact each site just connects to it's dedicated database server and then jumps to the common code.)
I've invented a lot of features for my CDS that I'm sure some of them would be desirable to SMF users. My IP2Location (http://custom.simplemachines.org/mods/index.php?mod=1320) mod was based on an idea originally implemented on my own CDS, probably the first one to get ported to SMF. Since then I've added dozens of features to my CDS that would be easy to port to SMF.
So maybe I should pick "2.0.6 - 2.0.99" as my delimiter.
Lainaus käyttäjältä: Deprecated - tammikuu 22, 2014, 03:47:26 IP
Is there any way to include 2.0 in that?
Now that I think about it, matchPackageVersion() was recoded for 2.0 final. So what I suggested initially probably won't work well with Beta and RC versions. The best range will probably be the following, indeed:
<install for="2.0 - 2.99.99">That range will most probably cover all Beta, RC and final packages. I'm not exactly sure if you can make it so that only Beta 4 and above are acceptable since until it was recoded, matchPackageVersion() was very unpredictable. (like from what I remember, Beta 4 or RC2 was considered to be within 2.0 - 2.99.99 range, while it actually wasn't) Maybe listing all acceptable versions separated by commas could work but it's probably not worth it.
No, code changed between Beta4/RC2 and 2.0.6 in the area affected by my mod. My original mod was locked with no future versions allowed. I wanted a cleaner way to do it, but I guess my best bet is to just retain the version locked install/uninstall, and then provide a 2.0.6-2.0.99 version to cover everything between now and the MAJOR. Then I can regulate it to some degree by checking compatibility boxes on the Mod Site.
Thank you everybody for your suggestions. I now know what I need to do.
The recommended way is to simply support 2.0 - 2.0.99. No-one should be running RC software at this stage because all RC versions have known security issues.
I can't support 2.0-2.0.99 because my package in question fails just past Beta 4 or RC2 or something. I'll have to start it out at 2.0.6 because that's the earliest late version I've tested it with. I agree that nobody should write mods that are unlocked for revs past 2.0.99. We all know that 2.1 will change everything, possibly break ALL the mods.
Somewhere between RC2 and 2.0.6 the SMF releases broke my code, so I just won't support versions between, because I'm not going to create a dozen test sites and find out which revision broke my code.
Anyway everybody should upgrade to 2.0.7 ASAP anyway. We all lose when sites won't upgrade. Some of the bug fixes are security fixes.
I've taken apart sites before that had a security compromise, and put them back together. Not fun.
So drop the code for those versions. They're not supported any longer, strongly discouraged because they have gross security violations (there are approximately 65 known vulnerabilities in RC2)
Make life easier for yourself by only maintaining the current code.
I'll just reissue the package with no changes for SMFs before 2.0.6. Whatever was will always be. No practical way for me to fix that. Anyway, no button on the Mod Site except for 2.0.7 compatible. The mod is still compatible with all the versions it was compatible with before. Currently compatible with 2.0.6 and 2.0.6 with changes. No way I can affect anything else, not in practicality.
I was just trying to save lines of code in my XML. I can see now it's easier to just have more lines and let it will be.
No, saving lines in your XML means dropping support for out of date versions so you only have the code you actually need for current versions.
Still, I can see that you're continuing to ignore the advice I'm giving you, that's fine, have fun.
Lainaus käyttäjältä: Sir Cumber-Patcher - tammikuu 23, 2014, 12:13:17 AP
So drop the code for those versions. They're not supported any longer, strongly discouraged because they have gross security violations (there are approximately 65 known vulnerabilities in RC2)
Make life easier for yourself by only maintaining the current code.
(Simultaneous post.)
I'm not supporting those versions. It's just that I'm not in the business of telling people what SMF to use, and more importantly, some people install mods and then lose the mod packages. Mostly I'm trying to preserve their ability to use my latest mod package to uninstall earlier versions of my mod. They would be silly to install new mods on old SMF versions instead of upgrading to the latest SMF and installing new mods. That's why I'm involved in upgrading all my mods to 2.0.7. To make it easy for anybody who likes my mods to not have to make any choice between upgrading to 2.0.7 or having to do without my mods. I'll make sure they can have both.
I'll admit I'm trying to encourage people to migrate from 1.x to 2.x. I'm looking forward to SMF's 1.x EOL notice. I already have one mod that was 1.x only (to give them some of 2.x's functionality) and I've done the last update and notified them it was a final update, end of life for the mod. It will probably continue to work as long as SMF issues 1.x versions but people running 1.x have to understand that they're like running Windows XP. End of life coming soon. Migrate or get hacked. (Did you know that a lot of ATMs are running Windows XP?)
Lainaus käyttäjältä: Sir Cumber-Patcher - tammikuu 23, 2014, 12:19:21 AP
No, saving lines in your XML means dropping support for out of date versions so you only have the code you actually need for current versions.
Still, I can see that you're continuing to ignore the advice I'm giving you, that's fine, have fun.
The main support I'm providing is to maintain their ability to
uninstall my mods. You should just ignore me since you never read my full posts.
Lainaus käyttäjältä: Deprecated - tammikuu 22, 2014, 10:07:55 IP
No, code changed between Beta4/RC2 and 2.0.6 in the area affected by my mod. My original mod was locked with no future versions allowed. I wanted a cleaner way to do it, but I guess my best bet is to just retain the version locked install/uninstall, and then provide a 2.0.6-2.0.99 version to cover everything between now and the MAJOR. Then I can regulate it to some degree by checking compatibility boxes on the Mod Site.
Thank you everybody for your suggestions. I now know what I need to do.
I'm not talking about the changes that affect your mod. What I meant was changes to the function that Package Manager uses to determine if the SMF version of the install is between the range given by the mod. It was changed slightly during Beta and RC stages but was completely recoded in final version. Take the following range:
<install for="2.0 - 2.99.99">If you try to install that on
- 2.0 final, Package Manager will consider that 2.0 is between 2.0 and 2.99.99 range.
- Beta 4 or RC2 it'll again consider those versions to be in the range 2.0 and 2.99.99, whereas it shouldn't.
- 2.0 final emulating the version to Beta 4 or RC2, it'll tell you that those versions are not in the range of 2.0 and 2.99.99.
So 2.0 - 2.99.99 will cover pretty much all Beta, RC and final versions, whether you want it or not.
Just wanted to make that point clear. It's good to hear that you've reached a solution yourself.
do note.... the theory is that the OLD version of the mod, which they already installed and is still listed in their package manager list, is the one that will handle the uninstall - before they upload and run the installation of the NEW version.
I'm not sure why you think that you need to support uninstalling in older versions with your new mod versions.
Lainaus käyttäjältä: onepiece - tammikuu 23, 2014, 05:28:44 AP
So 2.0 - 2.99.99 will cover pretty much all Beta, RC and final versions, whether you want it or not.
Just wanted to make that point clear. It's good to hear that you've reached a solution yourself.
Yeah, that's exactly why I didn't want to use it. I'll just keep the old section that is locked to the SMF versions it works on, and add a new one that will be 2.0.6 - 2.0.99 and that will solve everything.
You gotta understand, I'm always looking for the shortest, most efficient way of doing things. I'm a perfectionist. Sometimes brute force works better.
Lainaus käyttäjältä: Kindred - tammikuu 23, 2014, 07:36:17 AP
do note.... the theory is that the OLD version of the mod, which they already installed and is still listed in their package manager list, is the one that will handle the uninstall - before they upload and run the installation of the NEW version.
I'm not sure why you think that you need to support uninstalling in older versions with your new mod versions.
I've known several people who installed the mod package and then deleted the source for the package. It's a stupid thing to do but sometimes people do stupid things. If it takes a little more effort on my part to cover them then I don't mind the extra work.