Development process

[Sadrul Habib Chowdhury]

* Jorge Villaseñor had this to say on [06 Apr 2010, 13:22:21 -0500]:
> 2010/4/6 Mark Doliner <mark at kingant.net>:
> > 2010/4/6 Jorge Villaseñor <salinasv at gmail.com>:
> >> I'm not proposing to switch to this very process neither kernel like
> >> process. But I guess we can adapt some of this ideas to pidgin's
> >> actual development process to be less erratic at releasing.
> >
> >> mayor: API/ABI breakage, remove deprecated stuff, remove public
> >> modules,etc  (done once in a while)
> >> minor: API aditions, libpurple/pidgin feature aditions, prpl feature
> >> aditions (done each time we have some new features ready)
> >> micro: pidgin/libpurple/prpl bug fixes, security releases. (done when
> >> there are bug fixes to be released)
> >
> > This mostly sounds good to me... I worry that strictly adhering to
> > these guidelines could make development more cumbersome and thereby
> > deter development.  But yeah, I totally agree with these ideas.
> >
> > --Mark
> >
> 
> Talking with elb, sadrul and kmstage in c at d.p.i I guess I need to
> clarify that I don't propose to release minor once a feature is added,
> but to delay features to minor releases.
> 
> A way to avoid detering development I suggest to have i.p.n.m as a
> main development branch, in this branch we merge every merge-ready
> feature branch so all developers can help to finish the cleanup and
> prevent regresions. Bugfixes get applied to i.p.p which must be
> propagated to i.p.n.m at least every week so our development branch
> have every fix done.

This sounds unnecessarily complicated to me.

Currently, for large-ish features (code-wise), we use separate branches
(e.g. for the X-status stuff), and merge with i.p.p (or i.p.p.n.m) when
they are considered reasonably complete. We use the i.p.p.n.m branch
for changes that add API, but aren't quite release-ready. I believe this
is working fairly well for us.

I guess what I am asking is, is there an actual problem that your
proposed scheme solves?

> As kmstage said in c at d.p.i we can manage to get a 3 weeks release
> cycle if we have a stable branch, in this case it would be i.p.p so it
> would be easy to make stable releases.

I think i.p.p has been relatively stable most of the time recently; at
least, I am pretty sure the stability of i.p.p hasn't been an issue for
delaying releases in a very long time. Lack of developer time (and
coordination, and interest?) is a far greater issue for releasing
frequently, in my view. (For example, right now, I believe i.p.p is
relatively stable, but have we considered when to release 2.7.0?)

Cheers.
Sadrul