ALERT: KDElibs (at least) 4.8.4 is actually 4.8.80+

[Nicolás Alvarez]

El 09/06/2012, a las 10:30, "Aaron J. Seigo" <aseigo at kde.org> escribió:
> 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  
>>> dumb.
>>
>> I'll leave the fist fighting to others, and would like to apologize  
>> 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  
>> necessary
>> one. It's perfectly reasonable to say "hey let's only do bugfix/ 
>> minimal
>> changes to *any* kdelibs branch for now, even if for everyone's  
>> convenience
>> we keep the usual branch structure".
>
> iirc, that's what we've done. 4.7.x libs branch was similarly  
> 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  
> all get
> used to it now because it could happen in future that Frameworks are  
> released
> on a different release cycle to applications so that "kdelibs  
> version ==
> workspaces version" will get broken. already kdelibs version != apps  
> version
> for many KDE applications, particularly many of the bigger ones like  
> digikam,
> amarok, kdevelop, calligra, etc.

Why not start now and make the next kdelibs 4.8.5? Releasing a kdelibs  
4.9 will just add to the confusion of how kdelibs development is  
working.

Even if we call it 4.9.0, it doesn't need a beta/RC. That causes  
problems because we are releasing multiple versions which *aren't in  
increasing order* and have overlapping release schedules (4.8.80 and  
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  
backported to the stable branch, or if already backported, reverted in  
the stable branch alone before doing the release (while master got a  
proper fix, eventually). We can't do that now because there is only  
one 4.x branch. In order to release 4.8.4, Dirk couldn't take the  
current 4.8 branch state and wanted to take an older revision and  
cherrypick other commits on top (I forget the exact reason of why this  
was needed, but I think it was because a recent merge in 4.8 broke the  
build). A previous revision had already been tagged as 4.8.80. On my  
suggestion, he made a 4.8.4 *branch* based on an older revision to do  
the needed cherry-picking.

After reading this thread, I see that was not the correct thing to do.  
If some commit in the 4.8 branch was not suitable for 4.8.4 for  
whatever reason, it should have been *reverted*. And IMO there should  
have been no kdelibs 4.8.80 at all.