Re: [vpn-plugins] don't maintain a separate stable branch nm-1-2 yet

[Dan Williams <dcbw redhat com>]

On Wed, 2016-05-25 at 17:23 +0200, Thomas Haller wrote:
> Hi,
>
>
> See https://git.gnome.org/browse/network-manager-openvpn/commit/?h=th
> /no-upstream-1-2-yet
>
> Quote:
> ========================================
>
>     Merge the stable branch 'nm-1-2' into master
>     
>     And don't maintain a separate stable branch in upstream, until
> 'master' bumps
>     the required NetworkManager API to 1.3. Until then, 'master'
> shall be
>     identical to 'nm-1-2' branch.
>     
>     For NetworkManager-core (which provides libnm) and network-
> manager-applet
>     (which provides libnma) we maintain stable branches like 'nm-1-
> 0', 'nm-1-2'.
>     This is useful, because those branches have different, backward-
> compatible
>     API that is used by other projects. But what is best for
> NetworkManager core,
>     is not necesarily best for the plugins.
>     
>     For the VPN plugins, with the release of 1.2.0 we also branched
> 'nm-1-2' off
>     'master' and since then maintained a stable branch upstream.
>     
>     This either means, we eagerly backport from 'master' to 'nm-1.2', 
> in
>     which case it's a lot of work with the effect of having two
> mostly
>     identical branches. In this form 'nm-1-2' isn't very useful.
>     Or we don't backport eagerly, which may or may not result in 'nm-
> 1-2'
>     being more stable. Especially since upstream NetworkManager does
> releases
>     infrequently, it can take a rather long time until we release
> 1.4.0 and an
>     improvement on master reaches the users.
>     
>     'master' still doesn't require >= 1.3 API from NetworkManager,
> libnm or libnma.
>     The VPN plugins are rather simple, and there is no strong enough
> justification
>     to maintain two separate branches, which both use 1.2
> NetworkManager API.
>     'master' shall always be in a decent shape. So, it's not clear
> that the
>     outcome of this is actually less stable. And there is no
> guarantee that any
>     branch, stable or not, is perfect. Downstream must be prepared to
> backport
>     necessary patches.
>     
>     This merge, resets the version number from 1.3.0 to 1.2.3.
>     
>     Also, on master we implemented the GTK plugin split, so the next
> release
>     1.2.4 (or 1.4.0, whichever happens first), will bring that too.
> That is
>     noteworthy, because it affects packaging as there are new files.
> But
>     that is actually a cool feature I'd like to see on 1.2.

Sounds OK to me too, though with a caveat that if there are large
changes to be merged (like OpenConnect's periodic changes to new
libopenconnect versions, or a large rework that could compromise
stability of the plugin) that the branches should diverge as long as
these large changes will not be ported to 1.2.

Dan