Branch for 3.4, 3.5 and the dev versions

[RussKie]

https://ci.appveyor.com/project/gitextensions/gitextensions-gerritplugin/builds/37643124

The original plugin was built against Git Extensions v3.4, in v3.5 there have been public API changes, that now rendered the current plugin (and all other plugins for that matter) incompatible.
The plugin must target a specific version of Git Extensions, and have branches for each version it targets.

[maraf]

What is the policy for supporting older versions of Git Extensions?
Isn't just enough to support a latest version GE with new plugin updates?

What works for "my" plugins, also written on a PR, is that I don't provide new features for older versions on GE. This way, next feature release always points to latest GE version. If I need to bug fix a release on older version, only than I do create a new branch from the release tag.

[thimmy687]

link #18

[RussKie]

Isn't just enough to support a latest version GE with new plugin updates?

We need to support at least two versions - the current official release and the dev version.
I suppose this can be achieved by a convention of calling branches after the app version a branch targets. I can't really see a reason for a plugin to maintain own versioning scheme.

I can't do such a great diagram as yourself, so bear with me.

master (targets GE master)
|
|
|-- 3.4 (targets latest GE 3.4)
|
|-- 3.3  (targets latest GE 3.3)
|

Once we release v3.5, branch the master into 3.5.
Old branches can be either merged into the main trunk or deleted after an arbitrary sufficiently long time.

[thimmy687]

We should also consider the versioning with respect to the supported versions.

[thimmy687]

Also in this thread again :)
Do we have any progress in this topic?

I'd like to spent more development effort in my free time for this plugin, but it's disappointing if we can't release also just small fixes like the line wrapping for weeks.

[mast-eu]

Sorry for my long absence.
My idea on this subject, and how I started to set up the plugin repos, is:

1. The plugin master branch always targets the GE master branch. What happened in https://ci.appveyor.com/project/gitextensions/gitextensions-gerritplugin/builds/37643124 was that changes in GE's API broke the build. I see this as a kind of "alarm", indicating that the plugin needs to be updated to these API changes first, before any other work can (and should) be merged.

2. Besides master, there are long-living branches release/X.Y. These are targeting the latest stable GE version, i.e. the latest available GE version at the time of the plugin release. Whenever a plugin is released in version X.Y, it's master is merged into release/X.Y.
   There are mainly 2 reasons for a new plugin release:

   • The plugin has significant updates that are release-worthy. Or a hotfix. In this case, the new and the previous plugin versions both target the same GE release.
   • A GE release has introduced API changes and the plugin needs to be updated accordingly.

I can't really see a reason for a plugin to maintain own versioning scheme.

Imagine a tight coupling between GE versions and plugin versions: GE v3.5 <=> GerritPlugin v.3.5.
Now assume there are changes to GerritPlugin and we want to release them. But no GE release is planed in the near future. What should be the plugin's version number? 3.6? 3.5.1? Both would imply limitations on the next GE version.
And the other way round: There's a new GE version, but the API hasn't changed at all. Do we want to bump all plugins, just to keep the version numbers aligned?