[Dev] Re: [Design] Proposal for 0.7 "mini-release" non-code
cubranic at cs.ubc.ca
Mon Feb 27 08:01:27 PST 2006
Sheila Mooney wrote:
> If we are setting the bar a bit higher and considering these "mini-
> releases" as something our users can download and play with, it
> brings to mind some questions around what non-code deliverables would
> be appropriate to support these "mini-releases". Based on some
> earlier brainstorming, I have put together a proposal to put out on
> the list for further discussion.
> Some high level thoughts and assumptions....
> + We need something light-weight. A full non-code release process
> with landing page design and documentation is not practical for these
> 2 month milestones.
> + We should leverage the current Chandler landing page we have now.
> + We likely would like to publicize these partial releases a bit more
> than past milestones so our current calendar users can have access to
> new features.
FWIW, Eclipse has its "milestone" releases on a roughly 6-8 week
schedule, so it may be useful to see how they do it on eclipse.org.
(Which they've just rejigged - again - but I hope I will get right at
least the basic features as they might pertain to this discussion.)
The downloads page lists at the top the most recent: official release,
stable build in the "next release stream", nightly build in the "next
release stream", and maintenance build in the official release stream.
Clicking on the build name in the build list links to a page (see
for an example) that at the top has a link to the "new and noteworthy"
page briefly describing new features (with screenshots! the surest way
to get someone to bother downloading and installing it) and a list of
download links for platform-specific packages. The build download page
also links to a collections of build notes, unit test results, and
performance results (those are all build automatically).
Of the major open-source projects that I've followed, I think this is
really the model that I like best. So with this in mind, these are my
comments on your proposal:
> + We would NOT create a new landing page for each milestone, we would
> use the existing 0.6 landing page.
> + We would not update the release number or download link on the
> existing 0.6 landing page. It's still possible we will have further
> patches to 0.6 and this would just get confusing.
So the landing page will have no link to download the new milestone? How
is one supposed to find it then? This contradicts your point #4 below,
so maybe I'm missing something.
> + The existing readme for 0.6 would NOT be replaced or modified.
> Instead we would have a new simple html page listing the new features
> and known critical bugs, very similar to the milestone report cards
> used in 0.6.
> + The feature list would be brief and not detailed step-by-step
> instructions on how to use any of the new features.
The feature list can be brief, but it has to have screenshots, IMHO. Its
main purpose is really to get people to try out the new milestone, and
screenshots are essential for that. It's not user documentation, so it
doesn't have to have step-by-step instructions on how to use those new
features - nor should it, because you want to keep it short and factual,
but also kind of "punchy".
> + A news section (or link) would be added to the current landing page
> with a brief "mini-release" announcement, download links and a link
> to the readme style html page.
How does this fit with your point #1 above about not having a download
link on the current landing page?
> + This news section could be simply a new button on the left nav.
I think it should be more then just a button tuck away to the side.
Maybe a section on the beta stream below that for the "official stable"
More information about the Dev