Skip to main content ↑ ↓
Topic: One click upgrade (Read 7000 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

One click upgrade

A couple of days ago I upgraded my WP install to 3.7.1, and in the "What's new" there is the fact that from now on micro versions of WP will install "in background", with the possibility to do some "beta testing" about the minor upgrades as well (I'm not brave enough to allow minor upgrades to be run without a backup! :P).

That is rather cool, and I think the mid-term goal (probably 2.0) should be exactly that: make the upgrade just a matter of decompress, run upgrade, be done with it and the forum is back to what it was just before the upgrade (including addons still installed and working as expected... if compatible).

Obviously to achieve that there is quite a bit of work to do:
1) make addons able to do everything is foreseeable from hooks or equivalents (i.e. template layers),
2) forbid addons to edit core files (and probably any file at all),
3) define guidelines to maintain a good level of backward compatibility,
4) probably other this, but now I have to go... lol
Bugs creator.
Features destroyer.
Template killer.

Re: One click upgrade

Reply #1 –

It's likely not the best place to write this, but since I can't find the topic I was looking for and this one is close enough, I'll post it here.
xref: http://www.elkarte.net/community/index.php?topic=1375.0

Somewhere, a while ago, I posted the proposal that while developing Elk, we should start dropping support for file edits, and we should do it progressively, starting with "some files" and the proceed with more.
What I would propose now is to drop support for file editing for any file in the modules directory (and all the subdirectories included).

Modules are meant to be self-contained functionalities, that extend the core without being strictly tied to it, sort of addons bundled with the core. The way modules are implemented should allow a huge flexibility and the possibility to extend them without having to rely on code edits[1].

For that reasons, I feel like these files could be good candidate for the "no-editing" policy.

Thoughts?
1 Actually it's not entirely true, but most of the cases could be covered that way.↵
Bugs creator.
Features destroyer.
Template killer.

Re: One click upgrade

Reply #2 –

My thoughts in general are dropping file edits is a bad idea.  Unnecessary restrictions to what can be done so people will just have to resort to other patching tools.  You already have one and it works.  You already announce on your mods if they make edits or not so people can rate the value / evil of mods and make their own choice.

Re: One click upgrade

Reply #3 –

Quote from: scripple – Unnecessary restrictions to what can be done so people will just have to resort to other patching tools.
Well, I see two problems here:
1) "unnecessary", it's not unnecessary, it has many more advantages that disadvantages. It may have a slightly steeper learning curve (if you are used to think the "file edit" way), but once you realize how more maintainable is the code and the forum, you start seeing the advantages,
2) "restrictions", it's not I want to put constrains on what can be done, the idea is to give tools flexible enough to let anyone do whatever they want (or close to) without having to resort to a practice that poses a burden on the maintenance and security of the site (I'm well aware of forums running vulnerable versions of SMF because patches cannot be applied because of file edits done by mods).

Anyway, it's not that file edits will disappear any time soon, at least we are talking about 3.0 (maybe).
The problem with file edits are the usual very well known ones and, from both developer and admin point of view, I'm pretty sure that, once the core is sufficiently extensible, edit files would become just a pointless hassle.

That said, to be more explicit, my proposal is not to "hack" the package manager and force it not to allow edit to these files, my idea is to document that patches will not do code edits to these files, but if needed, they will be replaced.
At that point people that like to edit files can still apply changes manually, and if they are nice enough they can even release a package that can do file edits on these files for the update.

Of course, my is a proposal, if there are good reasons not to enforce this policy at this moment in time, I'll accept the decision and postpone the beginning of the phase out, continuing to create patches with the "old" method.
Bugs creator.
Features destroyer.
Template killer.
 

Re: One click upgrade

Reply #4 –

I understand the theoretical advantages and the goal.  I'm not convinced how practicable it really is though.  No matter what you do mods will be written and then obsoleted by updates to the forum software.  Hooks will change.  Database and internal data structures will change.  Themes will change.  And so on. 

Some forums will depend on those mods but the author will have moved on.  Those forums will then still be unable to update because they will lose the mods if they do.  The same situation as today as anyone could update if they were willing to live without the mods.  Sure you can say "but the mods are self contained so it will be easier to update them".  Maybe, maybe not.  If you're not a programmer it really doesn't matter as it's all opaque to you anyway and you rely one someone else to do it no matter how it was done originally.  If you are a programmer you can look at the mod and see the changes it applied and probably not really face much difference in updating it either way.  The larger challenge is the non-programmer forum owner finding a programmer interested in helping out, especially for the cost the forum owner is willing to pay which in may cases for a free forum software will be pretty close zero.

And the disadvantages of doing it via hooks and triggers and such is not zero either.  Options are limited no matter how hard you try to make the hooks universal.  Often even if it can be done it will be done in a less efficient way.  Extra database calls to look up which hooks are in use.  Extra database calls in the mods themselves that would have been better combined with calls already made in the base code.  Extra conditionals around hooks that may or may not be in use.  Copying of whole functions just to make a small change to how the function performs.  The list could go on.

I've also discussed in the other thread the problem of changes that break mods not being obvious at update time.  Changes to the global variables, the passed in or returned variables, serialization formats, namespaces, etc. can all break mods yet at update there is no indication that anything that affects the mod has happened.  All kinds of odd behavior and lingering bugs can result.

I once briefly tried to use wordpress.  A zillion mods exist for it with various hooks to facilitate them.  It was a nightmare though because wordpress did not commit to any given API/ABI etc so each new release would break many mods.  The actively supported mods would get updated fairly quickly but many would take much longer.  You could wait around for all the mods to declare they supported the new version, drop mods that didn't and update, or update hoping the mods would work with no real idea of whether they would or not because you didn't know what they relied on what was were changed in the latest update.

I've already had mods that didn't do code edits broken by minor point releases of ElkArte because you changed internal serialization and there was no evidence anything would break until I updated and noticed the odd behavior.  And this was just a maintenance release 1.0.X  not 1.X or X.0.  It didn't help win me over to magic of hooks for maintainability.  With no stable API/ABI that just doesn't exist

That last paragraph is just to give a specific example for ElkArte.  It's not a complaint or judgement.  I think you all are doing great work here and I really appreciate it.

Updates to pretty much any software causes problems with mods/add ons.  Fortunately with open source software it's usually fixable.  However it does seem projects like to make it harder than necessary through arbitrary restrictions and removal of perfectly good functionality.  Like code edits.

This overall post is to give a counter to the desire to eliminate code edits.  I honestly don't see the big win from doing that especially given you have a pretty good diff engine to deal with it already.  In the end it's your software and you can do what you want with it though.