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


See https://git.gnome.org/browse/network-manager-openvpn/commit/?h=th/no-upstream-1-2-yet


    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.



Attachment: signature.asc
Description: This is a digitally signed message part

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