I'm actually looking forward to 2.0

I was actually disappointed when I saw "Elgg 1.10" instead of "Elgg 2.0"

Is elgg 2.0 going to ajaxify the activity page? 'cause that would be great1

Please don't get your hopes up about any particular feature. What goes into Elgg core is a function of available developer time, ROI of the change, the complexity it adds, and the number of decisions that must go into it. A version bump doesn't magically create resources to solve these problems.

Particularly the topic of "ajaxification" is huge and tough to nail down. Our current APIs are woefully underpowered for making things happen here so our shorter term goals are to improve these toolsets and empower developers in the community. Get out of their way.

i agree on not making a big deal about it, but i believe april is a bit too soon. I think June/July is more like it as plugin developers still need to catch up on the new release schedule.

Still i think we need 1 big topic to have for the 2.0 to justify not being backward compatible. It is easier to convince people to upgrade, as there needs to be a great end-user benefit (otherwise people do not think it is that valuable to upgrade).

Everytime we get close to a major release we talk about bc - will cool new features be included - what about plugin updates.

And I wonder why Elgg uses this asynchronous release strategy. Previous branches are maintained and released along with current. Why not release like wp for example?

Agree with Steve. We should set a date for 2.0 and cap the number/severity of breaking changes, and then just release in a non-eventful way sometime soon.

2.0 doesn't mean "tons of new features", "brand new direction for the project", or "ground-up rewrite". It just means there are intentional breaking changes.

I think we should strategically make the smallest breaking changes that open up the most doors for the project moving forward. Then we should try to warn everyone who might be affected as far ahead of time as possible and try to offer a smooth upgrade path if at all possible. Perhaps a wrapper API that they need to migrate to that will be compatible across 1.0-2.0.

I'd love to delete all the deprecated-* files, for example, but I actually don't know how much that would help us, practically speaking. Would that allow us to do anything we can't currently do? I don't see why it would. So maybe better to just leave all those in.

I very much agree with just getting out of the plugin devs' way for ajaxification. I just don't see us having the resources to do a huge UI rewrite.

Steve, what breakages do you have in mind?

I don't have anything in mind. I feel like we've halted most UI changes. We need to jump to PDO.

i think we should also standardize all plugins in how they work and how the files and views are organized. As discussed before (about consistency) we need to have a solid code base from where plugins devs can build upon or copy from. Standardizing all those things, will surely break a lot.

About the deprecated* files, we could move those to a plugin in 2.0 (to be enabled when needed).
 

Jeroen, There's already work towards a new standardization here: https://github.com/Elgg/Elgg/pull/7688. Chief problem is it's a whole lot of work for no immediate gain. I suppose we need to campaign for more devs to get involved.

Don't fear the 2.0

That's easy to say but actually what IS 2.0 really about? Everytime I read about - and again here in this thread - I read about the "BC breaking changes" but apart from that I don't get any clear image at all about the advantages or any specific features that really require breaking BC - or at least breaking them now.

Now I read about scheduling a date for the release of 2.0 and afterwards the discussions seems to be about what actually should be in 2.0. Shouldn't it be the other way round? First to outline the goals and then think about a realistic release schedule?

It might work for "minor" releases to say "we have no feature-driven release schedule but simply include what's done by the time the release date has come". But I don't think this makes much sense for a bigger overhaul that requires major changes in 3rd party plugins. If there's not at least some kind of plan of what is to be included in a major BC changing release to have an idea of what will come next after the release and how useful these BC breaking changes are in the long run, I see the next big BC breaking change just on the horizon even before 2.0 has been released. When should the 3rd party plugins be able to catch up?

It's already the 3-monthly "minor" changes that are very tight. And if you ask me, they are maybe too tight even. I know of no other larger project with such a tight release schedule. And "no BC breaks within a minor release" seems not fully true if you ask me - or maybe I have no idea what you really mean by "really BC breaking changes". I've about 50 plugins released here on this site. To test them all after a new minor release has been made takes me at least 1 month (I do have a main job and Elgg is just a spare time thing). 1 month for testing only - not even taking into account that a plugin needs to be updated for the new Elgg release. For Elgg 1.10 I've not even had time to start testing and 1.11 is to be released in less than 2 months already. To be honest, I begin to get slightly frustrated. If the small number of people developing plugins for Elgg are fully occupied with just keeping their plugins still working again and again on a newer Elgg version I don't expect that this small number will get any larger but rather the opposite.