New 1.14 RC date?

[Talden]

>> 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?
>
> Since I'm clearly not personally in a position to do any of this, and
> I must assume you know that, I can only conclude you're raising this
> rhetorically in an attempt to dismiss my argument.
>
> Moreover, I'm not the one who raised the need for which “build the
> developemnt branch regularly” was presented as an option, so it
> hardly seems appropriate to ask me if I'm going to support it.

No that was me (gulp).

Consider the situation though, we have a feature (brisbane-core) that
we must expose to a wider audience to ensure that it stabilises in a
more timely and thorough manner than if it remains accessible only to
the developer core. If we are not allowed to put this in a release in
some beta condition then surely we must make some other form of
release.

So while you were not suggesting we make builds of bzr.dev, it seems
to be the implication.

Some in this conversation (and I'll blame lack of sleep for not
recalling which participants) are primarily concerned with the
intention to get brisbane-core in at the expense of release timing at
the riskier end of the release cycle - and there's no question, end of
cycle is always riskier than start of cycle - We have to weigh up the
risk and ask if the risk is less concerning than a one month delay.

All advice seems to suggest an expected minimum of risk, and
developers and non-developer users are suggesting that they would get
value from a month earlier release.

> Of course. But if those features aren't in a released product, they're
> not susceptible to the blanket “it's been deliberately released so it
> must pass the ready-for-release threshold” perception that I've
> alluded to and think is quite a reasonable perception.

I'm concerned at the lack of respect for the users understanding.
There is no way a user can accidentally use the format and it is
clearly marked as a development format.

As has been noted, this has already occurred with 1.9 and the world
did not end. (Here I am referring the availability of the format, that
the merge to bzr.dev is immediately before release is a different
matter).

> I think more assurance is required than this; the default assumption
> should be “if it's not clearly ready for release, it's not ready”.
>
> You obviously have a different take on that, though. My arguments are
> on record, so it's for others to decide what to do from there.

This really does come down to an almost religious definition about
what may be placed in a release.  I am in the camp that says if we
protect the user from accidental use and clearly communicate the
condition of the feature then the only concern we need have is "will
this destabilise anything else and threaten the quality of the
release". (and yes I'm aware here that your definition suggests
quality has diminished).

--
Talden