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

On Wed, 2016-05-25 at 17:23 +0200, Thomas Haller wrote:



    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-
    (which provides libnma) we maintain stable branches like 'nm-1-
0', 'nm-1-2'.
    This is useful, because those branches have different, backward-
    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', 
    which case it's a lot of work with the effect of having two
    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-
    being more stable. Especially since upstream NetworkManager does
    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
    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
    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
    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.
    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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]