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 _______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
