| From Richard Ash <richard@...>
| Wed, 22 Jul 2009 10:18:43 +0100
| Subject: [Audacity-devel] How about several smaller releases on the way to 2.0?
> On Wed, 2009-07-22 at 08:19 +0100, Gale Andrews wrote:
> > > >> My vote is for a 1.3.9 towards the end of August, then a 2.0 rc
> > > >> (named as such, to counter the "yawn, not another Beta" syndrome)
> > > >> maybe end of September/early October?
> > > >>
> > > > Well, generally we don't actually release rc's until the final one,
> > > > which becomes non-rc.
>
> In the run up to 1.2.0 there were 3 (I think) pre-releases over a period
> of months which were for the same function as we are proposing -rc
> builds. I think this naming is less confusing, because it keeps -rc
> builds as internal tests, the last of which becomes the release.
Only less confusing to us, though I take the point.
> > > > I think if they're designated 2.0rcN, we could reasonably do them once
> > > > every 2 weeks beginning mid-September, so we'd at least get more
> > > > feedback on the nightlies.
> > >
> > > I'm in agreement - this would satisfy my attention span.
> >
> > I understood Leland's suggestion to mean we might actually release
> > a 2.0 rc (or several). I'm very unsure about "several", but I think
> > people might well be excited by and motivated to give feedback about
> > a "news-announced" 2.0 rc. Either way, we could certainly stress in
> > the news announcement of the 1.3.9 Release that we really want .
> > feedback on this because it's close to our final intentions for 2.0.
>
> Can I suggest that we do a 1.3.9 release as GSOC ends, i.e. the code
> freeze starts on August 10th, with an intention that the release is
> public by August 17th? This puts another line in the sand for progress
> forwards, and allows us to release the GSOC work to the public promptly.
> This would be the last beta release, headlined on the fact that it wraps
> up SoC work at the official end of coding.
Might it be better to wait to release 1.3.9 right after the actual
announcement of GSoC results on the 25th, then we can actually
say our students passed?
> > I'm not 100% sure of the details of what you're suggesting Vaughan,
> > sorry. Is it that we actually advertise these "every 2 weeks" 2.0 rc's
> > on the Beta download pages under "Optional downloads", where it
> > was suggested we might advertise the Nightly Builds? In other words,
> > don't advertise Nightlies on the Beta download pages yet, but try
> > these rcs there as an experiment? And these rcs have no news
> > announcement or formal web site update, for the reasons I think we
> > agree on?
> >
> > Even after those, I rather like the "insurance" of an officially released
> > "2.0 rc-final", 1.3.10 or whatever you want to call it, news-anounced
> > and with more publicity than we have given to Betas recently. Perhaps
> > we don't need it, but I have a feeling it might make sense.
>
> Once we have released 1.3.9 at end of GSoC we should be close to a
> release, and we then start building 2.0 pre-releases. The rule for these
> would be that we change only things that need to be fixed as a result of
> reported bugs. At this point we may need to create a branch in order to
> collect post-2.0 content (I strongly feel we should do it that way round
> not the reverse).
>
> I think we do need to publicise these more than we do at the moment,
> posting links to them onto the beta download pages would be good, as
> would posting the links as a forum announcement and to mailing lists
> (but obviously not the full announcement list). If we make the download
> page read "latest 2.0 pre-release (date)", then we only need to change
> the URLs and dates (in an include file) as the releases tick over, to it
> doesn't create translation churn.
Still not quite sure how the Nightlies might fit in here - if we go
for the principle of making them an optional "Beta" download,
we can't really drop them because we have a 2.0 rc - in fact the
nightlies are (at that time) effectively the "latest" 2.0 rc. And in
many ways after a 2.0 rc comes out and that bug is fixed in a
following "Nightly", that "Nightly" is what we want to be tested.
It might be wasteful after that to get more reports of that same
bug in the rc, except possibly it highlights the bug so we could
ask more people to test the fix. Any comments?
> We don't need to do any web site changes etc so the overhead should be
> pretty small - basically someone builds them, pushes them to a web host
> and posts the link. It would be nice to keep platforms in sync, but
> that's about it.
>
> I would envisage us doing this much in the same way as we did alpha
> releases last year, but against a much more stable code base because we
> should be almost ready to release.
Possibly/hopefully. I guess the problem is until we get the
volume of downloads that only a Stable will get, we will never
really know about the stability of the "Stable". That's the
reasoning behind the suggestion that what we consider as
the final 2.0rc actually is officially released with whatever
label you want to attach to it, in the hope it attracts significantly
more interest than your average Beta (even if more publicised
than normal). I would agree this should not normally be
necessary, but with a long list of intermittent/not understood
bugs, I am very uncertain about the true stability of what we
have now.
Thanks, Richard.
Gale
|
