Development process

[Jorge Villaseñor]

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.

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.

This schema will help people adding new features to write the code
avoiding adding API so it can be shipped in the next release. Plus we
don't need to wait a lot to release a minor version, just when some
API is added and we feel it's ready to be released. Then at release
time, propagate back to i.p.p and start the minor cycle again.