El Dimarts, 12 d'agost de 2014, a les 14:41:31, Sebastian Kügler va escriure: > 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.
There won't be "KDE SC 4.15" so no KDE/4.15 branch for kdelibs, it just dies in KDE/4.14, we can do as many 4.14.x releases of kdelibs as bugfixes we get and need. > 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. cloning after i killed the master branch will give you the 4.14 branch by default. Cheers, Albert > > Just a thought, ignore at will.
