Sadrul Habib Chowdhury
imadil at gmail.com
Tue Apr 6 15:25:43 EDT 2010
* 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?)
More information about the Devel