Middleman V4 Compatibility

[olliekav]

Has there been start on making this extension compatible with v4? The extension seems to be found okay and activated but the CLI command cannot be found.

Could not find command "contentful".

The documentation on what has changed is so light for MM at the moment I can't find what has been changed that might cause this.

[kaishiro]

@dlitvakb No problem - just figured I'd drop it here in case anyone else was running into similar issues. We were able to temporarily resolve it by self-hosting the old gem (https://github.com/kaishiro/legacy-contentful-middleman), but once this is updated we can get back on the main trunk.

Appreciate all the hard work.

[kaishiro]

@dlitvakb Just saw your update. Thanks for the quick fix!

[dlitvakb]

No problem! Sorry for the inconvenience

[rr1000]

@dlitvakb - I guess I'm a little confused.

I was expecting to use the newly merged V4 branch as a part of master, however the Gemfile still requires 3.4. What's the solution here?

[dlitvakb]

Hey @rr1000,

There is a branch called dl/upgrade-to-v4 which is compatible with v4 and is completely up-to-date with the latest features in the master branch.

Master branch will continue to be v3 compatible.

Cheers

[tysongach]

Hi! 👋

I’m curious why master is staying with Middleman v3, while v4 has been out now for just shy of two years? The readme of this project states that v3 is the “most used version”, but I’m not sure that’s the case anymore. I know this doesn’t provide a complete picture, but a quick check on RubyGems shows v4 with many more downloads:

• v4.2.1: 108,219 downloads
• v3.4.1: 69,607 downloads

Even if we want to maintain a v3-compatible version, why not put that on a feature branch for those needing that support and use master for the most up-to-date, modern version of the gem? It feels counterintuitive to create workarounds when using the most modern versions, and not for when using legacy software.

[dlitvakb]

Hey @tysongach,

It sounds like a good idea, I'll consider this when it's time to make a new release.

Maybe just make a new major release with the current state of the v4 branch and swap the master branch.

I'll bring this on my next PM meeting, as it's a super low effort task I may be able to squeeze it for this sprint.

Cheers

[tony-pizza]

Re: Publishing v4 compatibility to Rubygems - Maybe too constraining, but one way to continue to develop and publish both v3 and v4 compatibility simultaneously could be to peg the major version number to Middleman's major version number (so contentful_middleman 3.x.x would use middleman 3.x.x and contentful_middleman 4.x.x would use middleman 4.x.x).

Also, what's the v4-1.x-stable branch used for? Before reading this thread I started out with that branch because it has stable in the title, but then realized it's way behind master. If it's no longer used can we remove it?

+1 for moving v4 to master.

[dlitvakb]

Hey everybody,

A decision to make a new major release for v4 has been made and will be executed this upcoming week.

Regarding your questions @peeinears,

The v4-1.x-stable is the latest stable release of the v4 branch using the 1.x releases of the CDA SDK.

We currently have the advantage that we haven't yet reached a major v3 version of this gem, and therefore we could actually artificially bump it to v3 for MMv3 and create a new v4 for MMv4 and keep parity that way. That said, tying the release number of this gem to Middleman versions has the limitation of handicapping feature development for contentful_middleman itself. If an incompatible change was introduced in order to provide better developer experience, how would we be able to make a release without affecting existing installations? As releasing it as a minor or patch, would make CI tools or whichever build system people are running think it's OK to download the latest version, and builds would therefore break without notice.

Our plan

My current stand on this matter is to artificially bump the v3 branch to version 3.0.0, and create a new 4.0.0 release for the dl/upgrade-to-v4, also, make dl/upgrade-to-v4 the new master, and the current master change it to dl/v3-stable. Any new updates will only be applied to the MMv4 compatible gem, and v3 will be put on security updates mode. To avoid looking contradictory to the previous paragraph, I want to clarify, that in the case of a breaking change being added, as v3 will be only on security updates, it will remain unaffected, and therefore it will be safe to bump the version number to 5.0.0, thus, the upstream version will not be "version locked" with the middleman release, and will allow some wiggle room for improvements along the line. And the fact that version numbers for current v3 and v4 releases match, is a lucky happening that we are taking advantage of.

I'm still yet to have another discussion with my team on how to handle this with the least amount of hiccups possible. Therefore, if anyone would like to express an opinion on this, I would be extremely grateful.

Cheers

[dlitvakb]

This has been done. 🎉 🚢

Summary:

• Middleman v3 compatible final major release is 3.0.0
• Middleman v4 compatible release is now 4.0.0.
• dl/upgrade-to-v4 branch will continue to exist for a few months to allow people to migrate gracefully, this branch will receive no new updates.

This issue will be closed by the end of this week.

Please feel free to continue contributing and providing valuable feedback for our integration.

Cheers