From kde-core-devel Sat Jun 09 22:44:14 2012 From: =?utf-8?Q?Nicol=C3=A1s_Alvarez?= Date: Sat, 09 Jun 2012 22:44:14 +0000 To: kde-core-devel Subject: Re: ALERT: KDElibs (at least) 4.8.4 is actually 4.8.80+ Message-Id: X-MARC-Message: https://marc.info/?l=kde-core-devel&m=133928210332360 El 09/06/2012, a las 10:30, "Aaron J. Seigo" escribi=C3=B3= : > On Saturday, June 9, 2012 13:40:29 Andreas K. Huettel wrote: >> Am Samstag 09 Juni 2012, 12:57:16 schrieb Aaron J. Seigo: >>> now, i really don't understand the use of words like stupid and =20 >>> dumb. >> >> I'll leave the fist fighting to others, and would like to apologize =20= >> for my >> choice of words. > > cool; thanks for that.. this is the KDE i grew to love :) > >> I still dont think the decision to freeze master was a good or =20 >> necessary >> one. It's perfectly reasonable to say "hey let's only do bugfix/=20 >> minimal >> changes to *any* kdelibs branch for now, even if for everyone's =20 >> convenience >> we keep the usual branch structure". > > iirc, that's what we've done. 4.7.x libs branch was similarly =20 > frozen, and then > we bumped it to 4.8.x ... i assume we'll do the same for 4.9.x. > > personally, i think it is completely unnecessary and that we should =20= > all get > used to it now because it could happen in future that Frameworks are =20= > released > on a different release cycle to applications so that "kdelibs =20 > version =3D=3D > workspaces version" will get broken. already kdelibs version !=3D apps = =20 > version > for many KDE applications, particularly many of the bigger ones like =20= > digikam, > amarok, kdevelop, calligra, etc. Why not start now and make the next kdelibs 4.8.5? Releasing a kdelibs =20= 4.9 will just add to the confusion of how kdelibs development is =20 working. Even if we call it 4.9.0, it doesn't need a beta/RC. That causes =20 problems because we are releasing multiple versions which *aren't in =20 increasing order* and have overlapping release schedules (4.8.80 and =20 4.8.4 were very close to each other) from the same branch... In the past, broken or incomplete fixes in master would simply not get =20= backported to the stable branch, or if already backported, reverted in =20= the stable branch alone before doing the release (while master got a =20 proper fix, eventually). We can't do that now because there is only =20 one 4.x branch. In order to release 4.8.4, Dirk couldn't take the =20 current 4.8 branch state and wanted to take an older revision and =20 cherrypick other commits on top (I forget the exact reason of why this =20= was needed, but I think it was because a recent merge in 4.8 broke the =20= build). A previous revision had already been tagged as 4.8.80. On my =20 suggestion, he made a 4.8.4 *branch* based on an older revision to do =20= the needed cherry-picking. After reading this thread, I see that was not the correct thing to do. =20= If some commit in the 4.8 branch was not suitable for 4.8.4 for =20 whatever reason, it should have been *reverted*. And IMO there should =20= have been no kdelibs 4.8.80 at all.=