Skip to main content ↑ ↓
Topic: Preparing the 1.0.1 patch (Read 5677 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Preparing the 1.0.1 patch

I was preparing the patch for 1.0.1, and I'm having a kind of doubt.

One of the changes is the update of FontAwesome to the latest version (4.2), installing is of course not a big problem: overwirte the files and that's all.
Uninstall is another story, because to "properly" uninstall I'd have to add to the package the old files Elk is shipping now, or I'd have to just ignore them and leave FA 4.2 installed.
The last option is not include an uninstall at all in the package.

What is the "best" option for you?
Bugs creator.
Features destroyer.
Template killer.

Re: Preparing the 1.0.1 patch

Reply #1 –

Why would anyone want to remove patch? I'd go with not including option to uninstall package.

Re: Preparing the 1.0.1 patch

Reply #2 –

+1

Re: Preparing the 1.0.1 patch

Reply #3 –

I agree with phantom, that you wouldn't be really thinking about removing any updates :)

Re: Preparing the 1.0.1 patch

Reply #4 –

I'd think its safe to leave that updated dependency in place even with an uninstall,  Now if it was the editor I'd feel differently.  We should give some thought how we handle external dependacy updates going forward, maybe only at  full .x releases?

Re: Preparing the 1.0.1 patch

Reply #5 –

Remove entirely the uninstall is an option I would try to avoid even though is obviously a security risk by itself.
The SMF 2.0.7 patch is an example of why an uninstall is always a nice thing to have (I myself had to uninstall the patch from a forum in order to avoid the server to die every few minutes).

Quote from: Spuds – We should give some thought how we handle external dependacy updates going forward, maybe only at  full .x releases?
Good point, minor (x.y) are indeed fine.
Micro (x.y.z) could be a bit borderline, FA is not a big issue I guess, the editor would be a pain and I would avoid it for micro for example, unless broken.
Bugs creator.
Features destroyer.
Template killer.

Re: Preparing the 1.0.1 patch

Reply #6 –

Got your point.

Re: Preparing the 1.0.1 patch

Reply #7 –

I had another small peak of electricity in my brain and a flash about this one, but "forward thinking", not limited to 1.0.1, probably more about 2.0.1.

One of the original plans (as I remember it, I'm pretty sure it's also written somewhere around[1]) was to gradually phase out edits to files as a way to create addons.
The "gradually" part was intended like: the moment a certain file has enough ways to be extended that it doesn't need any edit at all, that file can be added to the hypothetical "no edits" list.
An example of files that could safely fit into that description are the payment gateways. Nobody should change them.

Assuming at some point we will create such a list, in order to update these "special" files, the only meaningful way will be to overwrite them.
And the moment we do such a thing, we will be again in this very situation: what to do with the uninstall?

I see two options:
1) provide a package with both the new and the old version of the file,
2) do not provide an uninstall at all.
In the current situation, of course option 1 is the only applicable.
In the future (when more code will be covered by automated testing), option 2 could become acceptable, because risks of regressions or of "disasters" should be much lower.

But as I said at the beginning, this is something for the future.
1 I would love a "converter" of double parenthesis into footnotes. It would be less typing. :P↵
Bugs creator.
Features destroyer.
Template killer.

Re: Preparing the 1.0.1 patch

Reply #8 –

Oh and I forgot: I can't see anything else to add to 1.0.1, am I missing anything?
 emanuele starts preparations for the release! :D
Bugs creator.
Features destroyer.
Template killer.

Re: Preparing the 1.0.1 patch

Reply #9 –

Not unless some more bugs are found  O:-)  I realized I forgot to add my last changes to the .xml file as well, so that needs to be done, should be able to do that tonight unless someone else gets to it.

And indeed, as we get to a no edit stance, upgrades become a lot easier and an uninstall would be nothing more than copy over the old files.

On another random thought, I'm wondering if we should provide a register addon type of function to the addon installs, this would call (based on some naming pattern) an add hooks method in the addon during install and remove hooks method during the removal.  Makes it easier to also have an enable / disable function in the acp as it could call the same functions.

Re: Preparing the 1.0.1 patch

Reply #10 –

Quote from: Spuds – Not unless some more bugs are found  O:-)  I realized I forgot to add my last changes to the .xml file as well, so that needs to be done, should be able to do that tonight unless someone else gets to it.
I think I already added everything (I'm using diffs between master and the latest patch_1-0-1 automagically converted to xml package file with my patch_to_mod script adapted to work with Elk, will push the code "soonish" O:-)), but a second pair of eyes is a good thing! ;D

Quote from: Spuds – On another random thought, I'm wondering if we should provide a register addon type of function to the addon installs, this would call (based on some naming pattern) an add hooks method in the addon during install and remove hooks method during the removal.  Makes it easier to also have an enable / disable function in the acp as it could call the same functions.
Yep.
I would love it. I think I proposed it here and there randomly.
From time to time I think at the possible pattern, but I'm still not sure how to make it work.
Bugs creator.
Features destroyer.
Template killer.

Re: Preparing the 1.0.1 patch

Reply #11 –

QuoteI think I already added everything (I'm using diffs between master and the latest patch_1-0-1 automagically converted to xml package file with my patch_to_mod script adapted to work with Elk, will push the code "soonish" O:-)), but a second pair of eyes is a good thing! ;D
Ah-ha thats how you did that, I was like holy shnikies how did he create that beast !

Re: Preparing the 1.0.1 patch

Reply #12 –

QuoteAssuming at some point we will create such a list, in order to update these "special" files, the only meaningful way will be to overwrite them.
And the moment we do such a thing, we will be again in this very situation: what to do with the uninstall?

What am I not understanding here? Why can't changed files be pushed out with regular releases as they are updated?
Success is not the result of spontaneous combustion, you must set yourself on fire!

Re: Preparing the 1.0.1 patch

Reply #13 –

hmm... not sure what you mean either... LOL
You mean the ElkArte_v1_0_1_install.zip? That will have of course the updated files. What I'm talking about there is update existing installations through the package manager. :)

In the meantime, I finished to pack the patch, but it needs testing!
I just installed it a couple of times on a test install to be sure it was the same as the "latest" repo, but a second (or a third) pair of eyes is always welcome. ;D

If you have already changed something during the development of the patch, you may get errors at install. ;)

ETA: and of course I forgot to add the execution of the code... lol

ETA2: re-added the patch.
Last Edit: October 04, 2014, 01:52:04 pm by emanuele
Bugs creator.
Features destroyer.
Template killer.

Re: Preparing the 1.0.1 patch

Reply #14 –

I installed it on a site with no problems.

I also installed a new version of 1.0 and then this patch, did a diff to the 1.01 branch on Git and there were only 3 differences and those were all extra, or not, newlines at the end of the files.

ETA: Please note you will need to uninstall SP, install 1.01, then get the new SP package to install.  We made some improvements in 1.01 so a couple (well 4) more source edits were removed from the portal :D
Last Edit: October 03, 2014, 07:12:50 pm by Spuds