We're aggressively pushing core JS to AMD and if you maintain plugins with JavaScript you really should convert to AMD now.

Oh "thanks" for pointing this out... If I start right now I'm sure I'll have updated my ~50 by tomorrow evening. NOT!

I've just managed to finish upgrading the last of my plugins to be finally able to upgrade from 1.7 -> 1.11 after about 3 years work. Some kind of break before having to start the next upgrade cycle would have been nice really.

I'm looking forward with interest to see ALL the core devs releasing updates of ALL their plugins for Elgg 2.0 at the day of release of 2.0. That is if you still maintain them even. If this sounds a bit sarcastic - well that's intended but not meant serious...

I've started a doc to outline our goals for views because this info is currently spread across numerous GitHub issues and PRs.

Sorry. But I don't get it. Maybe some words of explanation (for dummies) would clarify what the intentions are and what the possible consequences for plugins are.

I apologize for any confusion here. This doc was really meant for core devs and isn't a set of recommendations for plugin devs. We have a lot of ideas floating around and we need to get on the same page to keep the views system solid and BC.

I am actually really excited about the new views system that will ship with 2.0. It will be a core rewrite only, 110% backwards compatible. I say 110% because:

• it has exactly the same API
• it will allow backwards compatibility for moved views via what we're tentatively calling "view aliases"

Historically, if we wanted a single view to move to a new location, that would have been a breaking change. We did a lot of this in 1.8 and that was quite a nightmare... With this new system, we'll be able to make view moves invisible to plugins, as long as you're not doing anything unsupported like accessing the view directly from the filesystem. So core gets to stay nimble and keep refactoring, but plugins don't have to constantly keep up.

We've updated the doc substantially since this discussion started, especially focused on communicating the benefits of the changes to plugin devs.

Not to be a Donnie Downer but I'm having mixed feelings about this considering our timeline. I think specific paths for views would be valuable, but are implementable w/o an overhaul. The benefits of the rest seem very mild compared to the added complexity of aliases, and the opportunity cost of implementing, debugging, and documenting this right now seems high.

I think there are much more valuable features to add and dev roadblocks to clear at the moment, and views refactoring can go in 2.x with the pressure off.