KDE SC 4.5 schedule
Aaron J. Seigo
aseigo at kde.org
Tue Mar 30 03:36:47 CEST 2010
On March 29, 2010, Tom Albers wrote:
> Op Monday 29 March 2010 19:02 schreef u:
> > On March 27, 2010, Simon Edwards wrote:
> > > I strongly want to see an API freeze kick in at this time too. No more
> > > changes to APIs or header files (except docs) after this date,
> > > including
> >
> > the result will be poorer APIs than necessary. those of us working on new
> > API often do not get critical feedback on API related issues,
> > particularly the detail oriented sort. already some things leak through
> > and make it into final releases, despite doing API reviews at the
> > project level (e.g. on plasma- devel) and subsequently asking for review
> > elsewhere (e.g. k-c-d). the less time we have to do this, the more warts
> > that will slip through.
> >
> > i understand that the ballance point is binding releases, but i question
> > prioritizing those efforts over the sanitation of the C++ APIs that
> > underly them.
> >
> > if bindings need extra time to release, could we do bindings releases N
> > weeks after the Development Platform C++ release? this would avoid a
> > trade off between "rushed bindings" and "more warts in the C++ API".
>
> I don't think a separate release from kdebindings is managable in the
> current team.
fair enough.
> What we could do is a soft api freeze, where api changes are
> allowed, but need to be CCMAIL'ed to the kde-bindings ml.
that's doable.
> And set a hard
> api freeze (a week before rc1 tagging?) where no api changes are allowed
> anymore. Could that help?
if at all possible i'd prefer at the point of rc1 tagging so that we have the
full development time window to ensure API goodness. Simon (and other bindings
people): would that be enough time for you folks?
--
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43
KDE core developer sponsored by Qt Development Frameworks
More information about the release-team
mailing list