Craft 3 plugin backwards compatibility and maintenance for 2.x

Question

I've been updating a number of my plugins for Craft 3 lately; part of that process has been to create entirely separate repositories/projects to accommodate the differences between Craft 2.x & 3.

I'm curious to know how other developers maintain two plugins where the core functionality is essentially the same code.

Maybe having both plugins refer to the same dependancies via composer? (But still have two repos/projects)

Perhaps keep everything on one repo/project and simply have two versions of the plugin in there. Although that may conflict with Craft 3's plugin store; as half the files int he repo are redundant.

I'd love to know how others are dealing with their plugin upgrades and if there are any 'official' practices to resolve this.

Answer 1

This seems to be the common pattern emerging amongst developers in the same position...

A single repo:

craft-(pluginname)

Containing multiple branches:

v1 (your old Craft 2 version)
v2 (your new Craft 3 version)

There are a handful of variations to this, but that's it in a nutshell.

Examples:

• https://github.com/craftcms/contact-form *
• https://github.com/barrelstrength/craft-sprout-notes
• https://github.com/doublesecretagency/craft-cpcss
• https://github.com/marionnewlevant/craft-snitch
• https://github.com/carlcs/craft-deleteentryversions

* P&T has mentioned that they didn't prefix their own repos with craft-, since the repo is owned by craftcms. But they said they would have, if they were a 3rd party developer.

Some people have prefixed their repos with craft3-, but that has been discouraged by the folks at P&T. It would force you to abandon this repo (or leave the name confusing) when Craft 4 is eventually released.

Answer 2

As far as I know most people create a new branche in the existing git repo for the plugin. Unless you create an API with many external calls you won't be able to maintain one "core" file that can be used by both versions because of the differences between Yii and Yii2. Thus creating a composer dependency for shared files is out of the question for most plugins. That's only possible if the code can be used outside of Craft.

My company migrates all important plugins for Craft 3 in a new branche in the same repo but we don't really update the Craft 2 code and only do bugfixes when it's necessary. It would be too expensive to update the old version when you compare the benefits

You can handle it the way you like. There is no official guideline or a official "best practice" method. Like everything else in the software industry there are advantages and disadvantages and you have to find a way that fits your needs.

If you are going to maintain your Craft 2 support and if you want to continue to work for v2 plugins you'll need to migrate every new feature to your v3 version as well which can take quite a lot of time. If you are going to create future projects only with Craft 3 you might want to stop your development for v2 plugins.

Furthermore Craft 3 is more powerful so there will be features that are really easy to implement while it takes much more effort to do the same thing in Craft 2.

It depends what your company offers. Do you only sell "sites" I suggest to continue only with Craft 3 - if you sell plugins there might be people who refuse to use Craft 3 for whatever reasons or they need to include some new features so they still buy your Craft 2 plugin.