Plugin updates for legacy versions.

Answered

What the convenient way to provide the same updates for different versions of IntelliJ IDEA when it contains API changes in it?

For example, in 2020.1 was introduced method AbstractBundle.message and it's recommended to use it instead of deprecated now CommonBundle.message.

I decide to get rid of deprecated API, so I changed it. But this method didn't exist in 2019.3.4. That's why I started to support two different versions of the plugin.

And of course, I want to make updates transparent for my customers. 

So If someone installs the previous version of the plugin in 2019.3.4 he wants to transparently update his plugins with a common IDE upgrade.  (2019.3.4->2020.1)

But some users don't want to upgrade so quickly and still using an old version of your awesome product. And they also want to upgrade their plugins transparently (without changing channels of updates).

 

My question: "What kind of versioning system I should choose for my plugin?" or "What mechanism I have to use to resolve such a problem?"

 

Right now, I choose as an example:

 
1.0.0           2019.3.4
1.0.1 2019.3.4
1.0.2 2020.1 — 2020.1.1 (eap)

1.0.3 2020.1 — 2020.1.1 (eap)
1.0.3-2019.3  2016.1 — 2019.3.4

and the next will be

1.0.4 2020.1 — 2020.1.1 (eap)
1.0.4-2019.3  2016.1 — 2019.3.4

and in the future it can be

1.0.546 2100.1 — 2100.1.1 (eap)
1.0.546-2020.1 2020.1 — 2020.3.4
1.0.546-2019.3  2016.1 — 2019.3.4


Will it work?

 

P.S. It's from https://plugins.jetbrains.com/plugin/14069-magic-advisor/versions

6 comments
Comment actions Permalink

That way of releasing plugin would work - I've been using it lately with .ignore plugin as well, and each version had its dedicated branch, i.e.:

- master - plugin targeting the latest available IDE

- 2019.3 - a fork from the master, targeting 193,

- 2018.3 - a fork from 2019.3

Then, when implementing new feature/bug fix - I did it in master and then merged it like in a waterfall to the other branches.

However, my current release also contained version suffix to avoid misunderstandings.

0
Comment actions Permalink

Thanks for the answer Jakub. Should we be building with the same platform version that we are targeting? For example, a plugin that targets 2019.3, I would build with 2019.3.

0
Comment actions Permalink

Definitely yes - that's the safe choice.

In the .ignore case, each branch has a different IDE version stored in gradle.properties.

And to avoid merging issues every time, this file is added to the .gitattributes file so finally it's ignored when merging - read about this method, fits well with such branching solution: https://github.com/JetBrains/idea-gitignore/blob/master/.gitattributes

0
Comment actions Permalink

Perfect, thanks.

0
Comment actions Permalink

Thanks for the answer, Jakub Chrzanowski.

.ignore plugin uses a bit different approach.

1.0.1.2019 -> 1.0.2.2020 or 1.0.2.2019 -> 1.0.3.2222 or 1.0.3.2020 or 1.0.3.2019

I proposed

1.0.1 -> 1.0.2 or 1.0.2-2019 -> 1.0.3 or 1.0.3-2020 or 1.0.3-2019 

If my approach still works then great. I will think about a painless moving onto your approach. I think it's less confusing =)

0
Comment actions Permalink

I've been using the branch-per-platform method with combined version numbers (like 1.9.1-2020.1) for a couple of years now, it works great and IMO is the only workable solution for a largish plugin.

Nice trick with the .gitattributes too Jakub, thanks - I didn't know about that one.

1

Please sign in to leave a comment.