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.
http://download.eclipse.org/eclipse/downloads/index.php
Clicking on the build name in the build list links to a page (see
http://download.eclipse.org/eclipse/downloads/drops/S-3.2M5-200602171115/index.php
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"
release?
Davor
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
