On Oct 31, 2007, at 4:53 pm, David Chelimsky wrote: > We're going to a release model in which 1.odd.x will be considered > experimental. This means that while we will document code-breaking > changes in subsequent releases (so you know what to do to move > forward), we will not commit to backwards compatibility to these > releases.
I've always been puzzled by this way of handling beta releases, which quite a few open source projects follow. What's the thinking behind a 1.odd, 1.even pattern, as opposed to offering 1.x and trunk? (It's not hard to fetch trunk and build a custom gem - I've got a seven line script that does everything, including the TMBundle.) > When we're ready to commit to a given API, we'll release 1.2.0. After > that we will be committed to backwards compatibility to 1.2.x (which > will implicitly remain compatible with 1.0.x). If 1.1 introduces breaking changes, but 1.2 is backwards-compatible with 1.0, what happens to the API changes that appear in 1.1? Ashley -- blog @ http://aviewfromafar.net/ linked-in @ http://www.linkedin.com/in/ashleymoran currently @ home _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
