KDE Frameworks Release Cycle
neundorf at kde.org
Mon May 5 20:54:42 BST 2014
On Sunday, May 04, 2014 16:27:44 Luigi Toscano wrote:
> Kevin Ottens ha scritto:
> > So, we had a team discussion here with Albert, Aleix, Alex, Alex,
> > Aurélien,
> > David, Rohan and myself. We juggled with several options, trying to
> > address
> > the following constraints:
> > * We don't have many contributors;
> > * We don't have enough testing in the stable branches, developers tend to
> > have a hard time to dog food those;
> > * We don't have enough contributions coming from the application
> > developers
> > because it takes a lot of time for them to benefit from their changes so
> > they tend to workaround instead and consider kdelibs more and more as a
> > black box; going forward we don't want that for KDE Frameworks.
> So, I've seen no discussion about this (not on this list, I think it's going
> on somewhere else) but I would like to rise my concerns with this decision.
> It can increase the "balkanization" of the version shipped by distribution.
> This is going in the opposite direction of the advocated "give users a real
> KDE experience". With no stable branches, distributions will have to
> randomly choose one branch to stabilize and the risk is that based on their
> schedule, they will choose different versions, heavily patching them
> (_more_ than what happens today, where there are few synchronization
> Other big projects with frequent releases, like the Linux kernel or Firefox
> have stable branches too; not all of the releases, but some of them. Firefox
> had to provide a "esr" version (long support, one year) because it's not
> really possible to update an entire stack in long-term supported
> distributions. And Firefox is mostly a leaf in the dependency tree (with the
> exception of libnss and libnspr, which can break and broke in the past from
> one esr to another); here we have an entire bunch of "core" libraries (as
> in Linux with its long-term branches).
> I understand that the big concern was about the testing: stable branches did
> not receive the same attention, but I think that killing them is not the
> solution; solutions include an increase number of automated tests (unit,
> integration, scenario) as first step, and a bit of time invested in the
> rest (manual) testing, with contribution of distributions but not only
> them. We had a lot of coding sprint, we can organize test sprints as well
> (which benefits also the main master branch, of course!)
> I also think that many frameworks will stabilize after the initial rush, so
> it will. I suspect (just a feeling, not backed by any fact) that Tier1 will
> stabilize sooner, Tier3 will have more moving part (please note that this
> is not about ABI/API, which I'm sure will keep the compatibility as it was
> before). If this is true, it could help in creating "naturally" stable
> branches; KDocTools is a good example, it's unlikely to have new important
> changes too frequently, but I guess it will be the same for KI18n and
> Minor point: the original statement of "three releases" for Porting Aids
> should be fixed to be time based (I guess at least 6 is not 9 months).
> So, my proposal(s).
> I think that some kind of long term branch branch is needed. It could be an
> yearly release (and we could do a testing sprint for that, solving the
> problem for the "love"), or a bit more frequent, like twice a year (no
> more!); still at least one release could benefit from a sprint.
> Collaboration from distribution is needed, so that they can coordinate. In
> case of yearly releases, if few distributions want to have an official
> stabilization branch (like in Linux) they will able to create and manage a
> special branch (with some input from developers).
> After the initial rush, revise the release schedule in the light of the
> "stable" frameworks, maybe they can be "naturally" on a stable branch
> (because no big changes will land in them).
Maybe this should be considered seriously ?
If we have more than 50 libraries, do all of them need a full new release
every month ?
As Luigi says, some of the smaller libraries may not see many changes at all,
and maybe only "old style" patch level releases for them would be good enough
More information about the kde-core-devel