No more migrations until 2.0?

After 1.9 I'd like to have a certain guarantee of stability and backwards compatibility all the way through 2.0 in keeping with http://semver.org. If we can put off data migrations and backwards compatibility issues until then, I think we should. Any objections to that?

  • How could we object to that :-) ? I am more concerned about your plans for 2.0 which seems a migration nightmare. As it seems long away from now, I hope we can come to some middle ground on the way.

  • Seems reasonable. Was there something in the queue you were thinking of here?

  • Just interested in getting to a 0 overhead state for maintaining the community. Being able to live at the bleeding edge of master would be a key part of that, but that can't happen if we're introducing breaking changes, even small ones.

  • I'm not completely sure about this yet. I will have to review in more detail what I have had in mind and what we have in the issue tracker.

    Is maintaining the community site your only concern?

  • Also concerned that making breaking changes without bumping the major version number is basically lying if we want to claim we're following semantic versioning.

  • If we're serious about semver, today's master branch should be 2.0. Of course we've done our best to allow most 1.8 plugins to work, but no one familiar with master can with a straight face say that it has no BC-breaking changes.

    If we're really hung up on releasing something called 1.9, we need to cut a new branch and back out changes like comment/discussion migration, CKeditor, and other removed stuff.

  • I assume 1.9 would be the last release NOT using semver. After it we would stick to the the new way of versioning.

  • Yes, 1.9 would be the last non-semver release

  • I remember an old conversation between Evan, Cash, and me when we first started being mindful of semver releases about what constitutes API changes in Elgg. A sticking point was views. IIRC we never came to full agreement about what changes would be allowed and what wouldn't. In the strictest sense, all views are public API and so wouldn't be able to change until major releases.

    If we can put off data migrations and backwards compatibility issues until then

    To be clear, do you mean to avoid making changes that would require a BC layer until 2.0?

    Being able to live at the bleeding edge of master would be a key part of that

    The core team doesn't develop this way, so I don't think that this is a desirable goal currently. Our dev practices have been to consider master unstable, and use branches / tags to point to stable code. We'd need to change our dev workflow to consider master suitable for prod environments. 

Feedback and Planning

Feedback and Planning

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