On Oct 31, 2007 11:36 AM, Scott T. [email protected]
wrote:
When can we expect the next release of rspec?
Definitely by the end of November.
Likely by mid-November.
Hopefully in a matter of days.
The next release will be 1.1.0.
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.
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).
Hope that all makes sense. This will give us the best opportunity to
get features out early with an understanding that they are subject to
change, while still allowing people who choose not to absorb that risk
to get features as they become less volatile.
Cheers,
David
On Oct 31, 2007, at 4:53 pm, David C. 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
On Oct 31, 2007, at 11:56 AM, Ashley M. wrote:
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.)
Can I get that! That sounds nice… (probably simpler than i think)
On Oct 31, 2007 1:56 PM, Ashley M. [email protected] wrote:
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?
Interestingly enough, there is another thread today expressing
dissatisfaction with 1.x and trunk. Can’t please everybody
On Oct 31, 2007, at 7:33 pm, Jim D. wrote:
Can I get that! That sounds nice… (probably simpler than i think)
Sure, this is all there is to it:
2> ~/Documents/Development/bdd % cat update-rspec-gem.sh
#!/usr/bin/env bash
cd ~/Documents/Development/bdd/rspec-trunk
svn update
cd rspec
rake clobber
rake package
sudo gem install pkg/*.gem
svn update “~/Library/Application Support/TextMate/Pristine Copy/
Bundles/RSpec.tmbundle”
Note it assumes your RSpec.tmbundle is checked out of trunk, and not
either the MacroMates repository or the CURRENT tag, or something else.
Ashley
–
blog @ http://aviewfromafar.net/
linked-in @ http://www.linkedin.com/in/ashleymoran
currently @ home
On Oct 31, 2007, at 7:46 pm, David C. wrote:
Interestingly enough, there is another thread today expressing
dissatisfaction with 1.x and trunk. Can’t please everybody
You could always do what Rails does and offer a beta gem repository,
so you can install with --source ? That way you keep the numbering
uninterrupted and still offer a pre-built latest version.
Ashley
–
blog @ http://aviewfromafar.net/
linked-in @ http://www.linkedin.com/in/ashleymoran
currently @ home