New 1.14 RC date?

[Talden]

>> I think we've all had the experience of being unwitting beta testers
>> for supposedly release-quality code. Are we actually advocating that
>> the bzr devs be less honest about when this happens with bzr?
>
> Exactly the opposite: I'm saying that it's dishonest to release a
> product, yet knowingly do so with features that are not ready for
> release.

Well there's really no dishonesty here.  The formats clearly denote
their development status andrequire explicit expression of intent to
use them.  IE they must actually ask for a format called development.
Now we could use stronger language for the name perhaps -
"beta-format", "unstable", ...

> The honest thing to do is to acknowledge that some features *are not
> ready*, and lower the barrier for wider participation *by those who
> choose to participate*. Having the features in the official release is
> not the way; choosing to install and run a different product is.

How many times have we seen users select the wrong install due to lack
of understanding - the downloads page is just another aspect of the UI
as far as the product affects the user.  If we can't make it clear in
the application UI that a feature is development only, the same is
somewhat true of offering multiple downloads.

>> I seem to be hearing the developers say that the only proven way to
>> get that broader testing is to let people play with beta formats
>> without having to reinstall bzr.
>
> I'm saying that this has also proven to have bad effects, as described
> elsewhere in this thread. I'm also saying there are ways to increase
> exposure without slipping the not-ready code into an official release.

Agreed there are alternatives (regular dev builds perhaps - whether
the resources are available to automate it is another matter - this is
open-source after all) but as to whether they really protect users any
more than the 'development' moniker on formats...

--
Talden