On 21 July 2013 11:30, Jeroen De Dauw <jeroended...@gmail.com> wrote:
> Hey, > > > > you're adding in a whole new set of incompatibilities. > > > > > > How so? > > > > > > > > Extensions that use any of these extension libaries now depend on the > > version of MediaWiki and the version of the extension. That's a new set > of > > dependencies that can be incompatible now. > > > > It adds a component as dependency yes. It however does not add code as > dependency. One of the main reasons for creating well designed components > rather then throwing everything into one bucket is that it minimizes source > code dependencies. If you minimize dependencies (as a good programmer > should do on all levels), you also minimize the things that can cause > compatibility conflicts. It thus certainly benefits the user. > > Imagine you have a package P, which contains components A, B and C. Only > package P is versioned and released. That it could be split into 3 packages > is a detail not visible to the end user. A is stand alone, B depends on A > and C depends on A. You want to install extension E0 that depends on P v1.0 > or later. In particular, it depends on B, though again, the end user does > not know this. You want to make this install on a wiki where you already > have E1 installed. E1 depends on P v0.5 to v0.8. Internally it only cares > about C. This situation means you can in fact not install E0 and E1 at the > same time. The only reason for this is because to many things are packaged > together. If B and C where in their own packages, there would be no issue. > > So one can for instance go from depending on package ABC that contains sub > components A, B and C to depending on A and B. That's two packages instead > of one if you look at it naively, though two components instead of 3 on > closer investigation. It is quite bad to force users to care about C while > there is no reason for doing so. They'll be affected by any issues that > occur in C for no good reason. Every time ABC has a new release because > something in C had to change, users will have to deal with this release, > since to them it is not visible this is pointless. > > These are simple examples, with one component that could be split into 3. > The problems for the user get significantly worse if one throws more things > together and as this problem is replicated in the dependency chain. > The fact that this thought experiment is almost impossible to visualise without pen and paper is symptomatic of the problem. The end user of MediaWiki doesn't care about arcane internal dependencies, or the rationale for them, they want it to Just Work. So either the system has to actually * be* simple (version X of an extension requires version Y of MediaWiki, so if I update my MW install I need to also update extensions (or vice versa)); or it needs to be *properly* abstracted behind a system which makes it *appear* simple (you run some script and everything magically works or gives you informative explanations of why it didn't). The former is obviously preferable in terms of clarity and maintainability; and that is realised immediately if all essential components are properly backwards-compatible. There should never *be* a dependency of the form "package X *no later than* vY". That is a fault of package X, not of the extension which depends on it. Package X should have been properly managed so that its public signature does not change incompatibly; and if a change is necessary, the change is managed over several versions so that consumers can safely update their use of the new signature and increase their dependency version to the one which introduces the new behaviour. "I need all my components to be sufficiently recent that they support all the features I want" is a methodology that end users can understand (and also one which means that they should *always* be able to get the feature set they want). "I need to calculate the intersection of the dependencies of all my features and resolve them manually or automatically" is not; especially when there may not even *be* an intersection. None of that is in any way groundbreaking, it's just basic design principles which I think we all subscribe to, even if they don't always materialise. The point is that MediaWiki is *much* more likely to be able to police and maintain that proper signature management in core code, than in extensions and obscure miscellaneous modules. It's great that modules like Diff have good beady eyes on code quality and portability, long may that continue. That is *definitely* the exception, not the rule, with extensions. Our core code definitely isn't perfect in terms of signatures, or even acceptable in many places. But it's getting better because that's where the most attention is focused. --HM _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
