Killing kdelibs master branch

Sebastian Kügler sebas at kde.org
Tue Aug 12 13:41:31 BST 2014


On Monday, August 11, 2014 00:23:15 Albert Astals Cid wrote:
> Hi there, I'm sending this e-mail to propose removing the master branch of 
> kdelibs.
> 
> We kind of already tried that when we froze it, but i am proposing to
> actually  delete it (and enforce with hooks it doesn't come back) from git.
> 
> Why I want to kill it now?
> 
> Next release is not going to be "KDE SC 4.15" but simply "KDE Applications 
> 2014.12".
> 
> It does not make sense to release kdelibs 4.15 as part of "KDE 
> Applications 2014.12", since it kind of defeats the purpose of the name.
> 
> So we should not have a kdelibs 4.15 release, we should just be killing 
> master and just doing some further releases of 4.14.x as bugfix, this way
> we  avoid people using a branch of kdelibs that will never be released
> again.
> 
> In the past we argued about the need to have new kdelibs versions since 
> some applications use KDE_VERSION_NUMBER as their version number and we
> didn't  want to break those apps.
> 
> Well, applications using KDE_VERSION_NUMBER as their 
> version number "are doing it wrong", as it will stop working once we move
> to  KF5, since there's no such concept as "KDE VERSION" there, so we may as
> well fix them now.
> 
> Any objection?

No objection, since I don't commit to the kdelibs repo that much, but a "but".

Not having a master branch would be confusing to me. It would be much more 
logical (and making kdelibs less special) to make the master branch what is 
currently KDE/4.14 and branch releases off of that, so KDE/4.15 would be 
branched off of master again. The policy of no features would still be in 
place, just that master always has all the latest patches, and releases come 
from that.

Reason, if I'm building kdelibs from git, my "autopilot" way would be cloning 
(which gives you the master branch, dunno what'd happen if there's no remote 
master in the origin), see master, and assume that I now have "latest" and 
that it is what I should do patches against.

Just a thought, ignore at will.
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9




More information about the kde-core-devel mailing list