Killing kdelibs master branch

[Albert Astals Cid]

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.