Semver and views

With the push for Semver compliance after 1.9 is released, we need to address a question about views: Are views considered public API and how should this affect changing views in bugfix and minor versions?

I'm bringing this up because there's some good discussion about the admin area's plugin page on GitHub, but depending on how we consider views, these changes might not show up until 1.10 if there's a BC way to implement them, or 2.0 if there's not.

I'm concerned that if we consider views are part of the public API, we will be restricting ourselves too much and will end up either pushing off features forever, or getting to Elgg 50.0.0 by next year. Semver.org does address this in its FAQ:

If even the tiniest backwards incompatible changes to the public API require a major version bump, won't I end up at version 42.0.0 very rapidly?

This is a question of responsible development and foresight. Incompatible changes should not be introduced lightly to software that has a lot of dependent code. The cost that must be incurred to upgrade can be significant. Having to bump major versions to release incompatible changes means you'll think through the impact of your changes, and evaluate the cost/benefit ratio involved.

I don't mean to imply that Elgg is a special snowflake, but Semver is heavily geared toward API libraries, and I don't consider it to be a direct correlation between traditional APIs and our views system. In traditional APIs, BC compatible changes are fairly easy to implement. It is messy, time consuming, and of dubious effectiveness to make BC compatible changes to views.

We need to find a balance that allows us to make incremental improvements at a pace compatible with our devs and users, but also to provide stability for the same. Other thoughts?

  • My thought for 2.0 has been to split Elgg into an API server and a web client and version them separately. This would resolve the conflict here because then each project has a much more limited scope of what constitutes the API.

  • My other thought is "who cares"? Why is increasing the versions bad? It tells people that they might have to do work to get it compatible with the new version, which is the same whether it's views or a traditional API.

  • I guess I'm not comfortable with just exempting views entirely but could see defining the API in a more limited way so that we're still free to iterate quickly on the UI.

  • I'm definitely not saying to exempt views, but we need to have some clearer plans on how to handle them.

    My thought for 2.0 has been to split Elgg into an API server and a web client and version them separately. This would resolve the conflict here because then each project has a much more limited scope of what constitutes the API.

    It doens't have to be a web client. If we release the engine and a "UI Plugin" separately we could accomplish the same without significant changes to the presentation layer. That's something we could do right now. This harkens back to what Elgg <= 1.6 did with a "core" package and a "full" package.

    My other thought is "who cares"? Why is increasing the versions bad? It tells people that they might have to do work to get it compatible with the new version, which is the same whether it's views or a traditional API.

    It's about increasing the minor version. Plugin developers have commented before about too quick a release schedule. If we are strictly enforce views as API, we'd probably be making more frequent minor releases since we'd not be able to make any view changes in bugfixes.

    I think probably the way forward here is going to make a list of inputs that we consider public API and guarentee those will be BC as specified in semver. What's on that list is the sticking point, though.

  • Why does a quick release schedule cause developers to whine? Is it because breaking changes were occurring too frequently? Is it because the deprecation policy means that we might soon drop functions they are relying on (1.9 means 1.7 functions can be deleted, according to our existing deprecation policy. I'm suggesting we not do that until 2.0 to keep plugin devs happy).

     

  • This is aside from views, but yes, the devs were getting upset because of the pace incompatible changes. 

    I'm suggesting we not do that until 2.0 to keep plugin devs happy).

    Which brings us back to the original question. What about views? If we guarantee views won't change until 2.0, we're locking ourselves in to not being able to update the interface at all until then. This seems overly strict and pretty abnormal in a project like this.

  • I can't see us locking ourselves out of all views being of any benefit for the project as a whole.  Is there even a subset that could be considered 'more important' for BC?  I can't think of any, beyond forms/form elements maybe.  Seems any view change has the potential for BC breakage.

    What has been the policy so far, say for 1.8?  I have a whole lot of plugins for 1.8 that haven't suffered any view related issues right from 1.8.0 to current.

  • One thing I'd say is that if our breakage is likely to obsolete the need for the plugins it is breaking, that's probably OK (e.g. admin area improvements fall into this category fairly often it seems)

  • What has been the policy so far, say for 1.8? I have a whole lot of plugins for 1.8 that haven't suffered any view related issues right from 1.8.0 to current.

    We haven't had an official one. We've made attempts to provide BC view and var wrappers, though.

    Is there even a subset that could be considered 'more important' for BC?  I can't think of any, beyond forms/form elements maybe.  Seems any view change has the potential for BC breakage.

    What if we consider the passable $vars options to view as the API and apply our BC guidelines to that, but the HTML generated by the views themselves are NOT API and subject to change? 

  • If every new minor release comes with the risk of breaking a bunch of plugins due to changes in views it would be a major hassle. Most likely not the same plugins would be affected every time (though... what about themes) but if every couple of months yet some other plugins fails to work and you have to constantly catch up (or hope for a plugin developer to release an update) it would surely spoil the fun.

    What about introducing some kind of fixed release schedule for major releases, e.g. once or twice a year, and trying to keep a BC layer for changed views included for at least the next two major releases? This would allow for continuing with the unmodified plugins at least for a certain time and allow the developer to upgrade the plugin within a reasonable timeframe. If the BC layer works, there would be no risk to introduce view changes with minor releases between the fixed major releases.

    Also, fixed release dates for major releases instead of a release depending on when some features are ready might lead to a more steady evolution of Elgg instead of an advancement in big leaps with long breaks in between. If a feature is not yet finished when the next fixed release date comes up it should not block the release but instead it will come with the next major release then (e.g. six months later). Currently, it's understandable that you want your code included for example in 1.9 if you might have to wait maybe a year or 2 for the next chance to get it out. But this might result in an even larger delay in the end as it might seem that the next release never get finished. If you know that you might have to wait only 6 months after missing a release deadline, you might take it more easy (and might even polish your code a bit more).

Feedback and Planning

Feedback and Planning

Discussions about the past, present, and future of Elgg and this community site.