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