On Tue, Sep 9, 2008 at 5:28 AM, Assaf Arkin <[EMAIL PROTECTED]> wrote: > Every release we make is an opportunity to fix all the reported issues > and bugs. And to break things that worked before. Sometimes both at > the same time, which to enough people translate into "nothing worth > upgrading for".
I know what you mean. I have this issue with release 1.3.2. It has several enhancement I'd like for my day job, but issue BUILDR-106 is a blocker, so my team is sticking with 1.3.1.1. > We need to be careful with what we change, how we change, and how we > roll out those changes. Especially changes that "remove" features, > whether by changing an API, behavior or simply breaking something that > worked before. > > I'd like to propose the following policy: > > 1. Concentrate major changes along minor/major version boundaries, not > point releases (i.e. 1.3, 1.4, 1.5, 2.0, etc). I agree with this idea, but I wonder what it means from an SVN point of view. When we add a major change, should we do it on trunk? on a branch? > 2. Maintain backward compatibility for at least one minor version. > For example, if we decide to remove a feature and the current release > is 1.3.4, we retain that feature for one minor version (1.4.x) up > until the 1.5.0 release. Fine with me. > 3. Provide deprecated warnings in documentation, API and when running > code. The warning should indicate what alternative exists, e.g. > "Please replace with using(:foo=>true)". Yes. That's something that's been done quite well in buildr. > 4. Maintain specs/tests for both new and deprecated behavior, until > deprecated behavior has been removed. To document this, I suggest we add expectations in our specs. E.g., it 'should do a deprecated behavior' do Buildr.VERSION.should < '1.5' ... end That way, when we reach version 1.5, we'll know automatically what needs to be removed. :-) > 5. Obviously there will be exceptions to this rule, but having a rule > we can at least minimize/contain these exceptions and know how to deal > with them. +1 Lacton
