On 23/10/2008, at 6:45 PM, Andrey Razumovsky wrote:
> Also I foresee I will soon work with ROP much more, and I'd like
> some other
> features on ROP to be done, like maybe lifecycle callback-like
> functionality. So I'd rather we limit "no more API changes" later than
> sooner.
Of course, 'no more API changes' doesn't mean forever :-) Just that
if we have a goal to aim for, then if you miss that goal, it just
means that the next set of API changes go into 3.1 (or 4.0).
So we can:
1. Decide on a feature set which will go into 3.0 then move all other
features in Jira to 'future'. If new features come in they go to
'future' and don't get added to the infinitely increasing list that is
3.0. OR
2. Decide on a date by which all new features are to be committed.
Then after that comes just bug fixing. This date based approach is
being used by a number of larger projects (such as FreeBSD).
Also, we should decide as a matter of principle, can the API change
between 3.0 and 3.1? Or wait until 4.0? Personally I think that API
changes should be allowed between 3.0 and 3.1 otherwise we split
development into too many branches.
Ari Maniatis
-------------------------->
ish
http://www.ish.com.au
Level 1, 30 Wilson Street Newtown 2042 Australia
phone +61 2 9550 5001 fax +61 2 9550 4001
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
This archive was generated by hypermail 2.0.0 : Fri Oct 24 2008 - 04:17:34 EDT