GeoServer : GSIP 43 - Roadmap and release handling process
This page last changed on Jan 27, 2012 by cholmes.
A proposal for long and short term roadmap process and its relationship with releases and testing. Builds son top of the GSIP 30 - Roadmap Process experience and tries to improve over it.
Should be driving the GeoServer development during the 2.0.x series
Choose one of: Under Discussion, In Progress, Completed, Rejected, Deferred
Never completed, and much of what it tried to accomplished has been iteratively improved.
As already stated in GSIP 30 - Roadmap Process we want a roadmap and release process that increases transparency and predictability, enabling all developers to participate in the planning and evolution of GeoServer, as well as allowing users to get an idea of where GeoServer is headed.
Compared to GSIP 30 this iteration suggest a different presentation of the roadmap and works a bit more on the details and responsibilities of the involved parties.
The road map is a time line of planned releases and features:
The roadmap is a document that anyone can read to get the pulse of the current and future GeoServer development. As such it's written in plain english and refers to Jira to provide a terse summary of the issues, both closed (work already done) and still open (work still scheduled for the next release).
Each release has a single page in the roadmap document, just like the download page we'll have a past, current and future releases structure. The current release pages are imported in the main roadmap page to get better Roadmap.
A single release page will contain at the very least:
For each release cycle two new people will be appointed to be:
These three figures might end up being the same person, and the same person can cover the roles for various months, thought it's advisable to see some turnover in those roles so that the load is shared (PSC members in particular are invited to share these responsibilities).
Each release announcement should thank the people doing the actual work, and the company(companies that allowed them to work on the release, if there was one.
The roadmap manager will perform a weekly update of the wiki page. In particular, this person will summarize the significant changes occurred during the week in a mail, check for outstanding work that has not been complete, and update the wiki page accordingly.
The release manager is responsible for warning the testing team and the developer team about the testing freeze, run the CITE tests (and report about failures) and of course do the actual packaging of the release on the assigned date. The release will be performed if there is no outstanding regression found by the testing team. In case regressions are found the package manager, the roadmap manager and the community will discuss about an alternate release date.
It is suggested that stable releases occur once every one month, but the actual timings will take into consideration the availability of a release manager, the current pace of development, the scheduling of funded features and critical bug fixes.
Once a release series enter maintenance mode, that is, when full development moves to another branch, a longer interval will be used (two to six months ideally), and the series will be eventually become unsupported as resources to work on that branch dry up completely.
New series will see a cycle with periodic betas, up until the developers feel comfortable calling the release a Release Candidate. The release candidate is a release that is considered solid enough to be re-released as final as is, without changes. As such, the RC will be subjected to a week of testing like a stable release..
This section should contain feedback provided by PSC members who may have a problem with the proposal.
State here any backwards compatibility issues.
|Document generated by Confluence on May 14, 2014 23:00|