New 1.14 RC date?
andrew.bennetts at canonical.com
Thu Apr 2 06:10:54 BST 2009
Ben Finney wrote:
> Robert Collins <robert.collins at canonical.com> writes:
> > I think the crux of this discussion may hinge on the definition of
> > release quality; and also perhaps on audiences. For various reasons
> > we have only one effective channel for getting code to users -
> > releases.
> The suggestion, made earlier in this thread, to make automated builds
> of the development branch, would be a way to address this without
> muddying the distinction between release and not-yet-release.
This trades one set of work and problems for another. Are you volunteering
to make this happen? Are you volunteering to help support users confused
about which version they need to download and install? What about to help
support users that installed the development version to play with and then
forgot they did so and then get burned?
I'm not at all convinced that this would actually be better, and it sounds
like considerably more effort.
> Andrew Bennetts <andrew.bennetts at canonical.com> writes:
> > This sounds like a failure of the support conversation rather than
> > of the contents of a bzr release. I'm sorry you got bad advice.
> As Robert surmises above, I'm arguing here for the sake of other users
> who will be in a similar situation in future. The communication error
> could easily have been on my side; I may have misinterpreted the
> My point is that *no* misinterpretetation or misunderstanding on my
> newbie-in-a-hurry part should even be possible to lead to the
> invocation of a not-ready-for-release feature in a released product.
> The way to ensure that is to never put such code into a release until
> it's considered *ready* for release.
It's possible for misunderstandings to lead to bad outcomes even with fully
supported features; e.g. “bzr revert” will, by design, destroy changes, and
new users getting terse advice on IRC could get bitten by that. Or someone
might be confused into publishing changed they didn't want to publish, etc.
Basically, if bad advice is being handed out all bets are off. You can't
fully protect users from misfortune, although obviously we try!
It's (close to) ready for a beta release. I honestly don't think the danger
of having a hidden-by-default option with --development in the name is going
to harm a user, and it will be a massive boon to making sure the feature
will be totally polished when it *is* fully released. Again, we did this in
1.8 (well after learning the lessons of the subtree formats) and no-one
noticed except people that were explicitly testing the format that was
released in 1.9. Why do you think this case will be different?
More information about the bazaar