El 09/06/2012, a las 10:30, "Aaron J. Seigo" <ase...@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.
_______________________________________________
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
