New 1.14 RC date?

Talden talden at gmail.com
Thu Apr 2 22:25:15 BST 2009


>> It has to be possible to express that something is not intended for
>> production use.  If we can't express this to our users effectively in
>> the UI, what makes you think we can explain it on the download page -
>> If we offered 'Bzr 1.14' and 'Bzr 1.15 early access', which do you
>> think users would download rather often?
>
> "Early access"... That's a strawman if I ever saw one. Offer "bzr
> 1.14" vs. "bzr 1.15 Beta", or "bzr 1.14" vs. "bzr development build",
> like many projects do. Are you really saying that in these projects
> it's common for users to download beta software accidentally?

At least as often as they are likely to

1. Read the help for formats and see 'development' as a format
2. Use development as the format specifier to create a branch or repo.

That is, if the belief is that we cannot inform our users in the UI,
why is there a belief that those same users will know which download
to select - many will simply choose the newest one.

> You're the only one talking about moral absolutes. I was talking about
> software engineering and release management.

then there was a miscommunication - the two are clearly separate
points (slipping releases or having beta content in a release) and
they have been discussed as such in this thread.  It did seem you were
opposed to dev-formats in release.

This comment seems to express that - sorry if it was a misinterpretation...

"Does not worry you stable, regular releases being *the* place to
"expose [beta software] to a wider audience to ensure that it
stabilises"?"

> And that can not be done if brisbane-core is in bzr.dev instead of bzr
> 1.14 because...?

Because I can't build bzr.dev - at least not until I solve the
dependency problems, something that is solved by someone else when
they build the release installer.

--
Talden



More information about the bazaar mailing list