[bazaar] [ANN] bzr-2.5b3 has gone gold !

[John Meinel]

>
> I think just saying "2.5b3 source is frozen" would be better.
>
> I think the term originally comes from proprietary software shipped on
> physical meda where they would make a 'golden' cd or iso.  There are
> some obvious differences, one being that at that point all the
> installer work was done, another being that the announcement was less
> visible to users than it is here.
>

Well it was meant to indicate that the version was finalized but not
distributed to users yet. And certainly because of hashing and poor support
for updating tags, etc, if there is a bug in 2.5b3 source that is only
discovered during packaging we still have to create 2.5b4.

Anyway, I'm pretty sure it was meant as lighthearted and fun to call it
"gold", and it seemed to fit. If people find it confusing, we can easily
change it.

> > It's further confused by <https://launchpad.net/bzr> announcing the
> > latest version is 2.5b3 which only has a tarball, rather than 2.4.2 or
> > the previous beta. Perhaps the expectation is most users go through a
> > less developer-oriented gateway, like the wiki, pypi, or one of the
> > other aggregation sites.
>
> I think Launchpad ought to be able to act as the project's home page,
> and the fact it can't offer separate stable and beta downloads is a
> bug (I think a filed bug.)
>
> One way we can work around it is perhaps not to mark the milestone
> released until it is complete with its packages.  I don't know if you
> can attach files to an unreleased milestone though - but this too
> could be fixed.
>

I don't think you can, yet. Because you attach files to the Release, not
the milestone.

> > Jonathan also noted that being able to re-roll the tarball in response
> > to packager feedback is useful. I agree that tagging a source release
> > without seeing if it has build issues on some platform or other is
> > suboptimal, but think the tagging first approach we have now is
> > probably the right compromise. There's too much manual work for
> > certain platforms to justify a RC each time, over a redo when
> > something goes wrong.
>
> Right, I think we want to aim for a process that gets the release
> right the first time, and when we do get it right having a separate rc
> (with announcements, packaging, etc) is just waste.  If there are
> problems in the tarball discovered during packaging we should just
> burn off that release and proceed to the next one.  Having multiple
> things claiming to be 2.5b3 is just asking for confusion.
>
> > The right solution here in the long term, is to
> > get the packaging well enough automated that we do it continuously for
> > trunk and run the test suite against the installed versions.
>
> +1
>
> I do wonder if it would be a better use of time to just have daily
> builds off trunk rather than specifically announced betas.  The
> drawbacks probably are that there are people who will use betas that
> won't test nightlies, and that some platforms don't have automated
> builds.
>
> m
>

If we had daily windows installers, that would help, but I do think we
still get a benefit for users to have the concept of
1) daily stable. Trunk passes the test suite, but maybe not on all
platforms, and it hasn't been dogfooded as developers for more than a day.
2) weekly/monthly stable. While this is just a cut from trunk, if we find
significant bugs we will create a new release, but we'll only create a few
of these total. 12 in a year +- a couple, vs. 365. Also plugins, etc are
much more likely to be useable in monthly increments rather than daily.
Daily is great for developers to know something broke, and fix it for the
next monthly.
3) 6 month stable w >1year support.

I may be wrong, but there is a lot of software that I wouldn't feel right
running a daily, while a monthly would seem ok. It's a 30:1 ratio of "which
do I pick", and how do I report bugs, etc. I'm having a hard time pinning
it down, but I do feel strongly that a monthly cadence is more useful to
users than a daily cadence.

John
=:->
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/bazaar/attachments/20111111/f2dcf981/attachment-0001.html>