[Mockobjects-java-dev] [IMPORTANT] Release Process

[Vincent M. <vm...@oc...>]

I went to the MockObjects web site .... and noticed that version 0.01 was
released ! <argh>

We'll consider this first release as a try .... and forget about it. Now I
would like use to agree on the release process. Can you review all the
following point and tell me whether you agree or not so that we can reach a
consensus. Once this is done we'll put a page on the web site explaining the
release process. Thanks

P1 - Releasing a version is a community action that we all need to decide
together (the committers of the project). Before *any* release, we will need
to agree on doing a release. This entails sending a message on the mailing
list asking for a vote on the release (I propose to use the Apache Jakarta
system for voting : http://jakarta.apache.org/site/decisions.html).

P2 - Long before any release, we need to define what will go into that
release, i.e. the list of tasks that need to be performed *prior* to that
release. These tasks will be listed in the
http://mockobjects.sourceforge.net/todo.html (todo.xml file in CVS). Tasks
can be proposed on the mailing list (such as the mail I sent on 1st of
august, entitled "[Proposal] Roadmap". Unfortunately noone answered so these
tasks were not entered in the todo page. I'm still waiting for an ageement
before entering them !).

P3 - The changes page (http://mockobjects.sourceforge.net/changes.html,
changes.xml file in CVS) need to be up to date at any time. The goal of this
page is not to described fine-grained changes in CVS like "I have corrected
a typo" but rather to advertise changes that are useful to end users (for
example: "Improved the Mailing-list example by ..."). As it is very hard to
remember everything that everyone has done, it is mandatory to fill this
page as we do the modifications and not to wait till the release to fill it.
At the current time, this page is *NOT* up to date.

P4 - Check list of administrative tasks to perform before any release :

A1 - Agree on a release (see P1)
A2 - Designate a release manager for the current release to perform
A3 - Ensure that no one is working on any part of the files (code freeze).
This is done by posting a mail on the list asking for a code freeze.
A4 - Verify that the todo.html files is up to date
A5 - Verify that the changes.html file is up to date
A6 - Verify that the features page is up to date and includes all features
available in all releases + the new ones of this release. Note: This page
does not currently exist but we should create it quickly. This is the page
that persons will look at the most often to see what features the Mock
Objects project has.
A7 - Verify that the news items on the index page are up to date (major
announcement should be listed there, a release is a major announcement - A
news item should be added that says which version has been released with a
link pointing to the changes page)
A8 - Perform a Ant build 'dist' on the release manager's machine to ensure
everything build fine including the tests, web site generation, ...
A9 - Tag CVS (with the name MO_0_01_RELEASE - example for release 0.01)
A10- Publish the distributables files to SF. In the release note area of SF,
put a link to the changes page
A11- Increase the version number indicated in the build.xml file by 1 (for
example, after 0.01, put 0.02)
A12- Write a release announcement in the news area of SF (with a link to the
changes page)
A13- Send a message to mockobjects-java-user and -dev mailing lists to
announce the availability of the release
A14- (optional) Send announcements to other mailing-lists (XP mailing lists
on yahoogroups, JUnit mailing list) and web sites (junit.org, objectmentor,
...)

... then relax ! ;-)

I propose that we start doing this immediatly and follow this process for
the 0.02 release.
Thanks
-Vincent



_______________________________________________
Mockobjects-java-users mailing list
Moc...@li...
http://lists.sourceforge.net/lists/listinfo/mockobjects-java-users