Eclipse Project: Releases, Plans, and Reviews

For each release, an Eclipse project is required to provide a project plan. The project plan is created at the beginning of a release cycle and may be modified throughout the cycle. The plan tells the community what the main areas of focus are in the project. This lets, for example, contributors know what kinds of contributions are going to be valuable so they can direct their attention accordingly. It also lets adopters know what to expect from the project for an upcoming release (which may help them to decide to get involved).
At the end of a release cycle, an Eclipse project is required to provide a release review document. For project committers, it serves as a retrospective. It is a chance to look back and reflect on the work done, decide what worked and what didn’t work, and start thinking about the next release cycle. For adopters it is confirmation of the plan and a last chance to update their own plans for how they will incorporate the project code into their own development schedule. For the rest of the community, the review document serves as a description of the changes and a way to learn about what’s new, what’s interesting, and what they should care about.
Our current system keeps track of all this information in a variety of different locations. Project plans are represented as XML files and are stored somewhere within the Eclipse infrastructure (the website, a source repository, or the download site). Basic information about the release, including the name and date is specified in release records in the project metadata in the Eclipse Developer Portal. Release records are relatively limited in terms of the information they can contain; they are restricted to just the basic information, along with links to the project plan, and new and noteworthy documents.
Release review documentation is currently provided in a variety of different formats (e.g. HTML, PDF, PPT, ODP). When a project wants to do a release, they need to tell me. I create a record in the Developer Portal and point that record to the review document that we now store in a corresponding Bugzilla record. Unfortunately, the current system makes no explicit connect connection between the release and the corresponding review document (I’ve added some code that uses some heuristics to figure it out).
Sounds awful. Right?
The new system that Nathan and I are working on brings all these elements together. A project can specify any number of releases, projecting as far as they’d like into the future. The project plan, rather than being in a separately-managed document, is part of the release record. It can be specified at the beginning of a release cycle and updated throughout. The review information is also attached directly to the release record; it too can be updated throughout the release cycle. I think one of the key benefits is that all of the information is kept together in a very consistent form that can be easily organized and disseminated in different ways. Revision management is built in so it’s easy to tell who made changes, compare and revert changes, and so on.
In my opinion, Nathan’s done a great job with the look and feel. Here is what the BIRT project’s 4.2 release looks like:
Note the separate tabs for different elements of the release. Note also that this is just display-only: I don’t have the necessary access to edit this project’s releases. I do, however, have access rights to edit information for the Dash project’s releases:
When editing, separate tabs provide access to the description, plan, and review items. And, again, there’s revision tracking and management.
So the big question: will you use it? Or do we need to provide the ability to attach separate plan and review documents?
I’ll be showing this off at EclipseCon 2012 at a BoF. If you can’t attend the BoF, corner me: I’ll be prepared to demo what we have to anybody wants to see it. We’re going to roll out a version of this that you can play with in the weeks following EclipseCon; with a plan to roll it out as a replacement for the Developer Portal and Data-Driven Project Websites post-Juno (i.e. July 2012).

Reference: Releases, Plans, and Reviews from our JCG partner Wayne Beaton at the Eclipse Hints, Tips, and Random Musings blog.

Related Whitepaper:

Emerging Trends in Project Management

Implementing soft skills into your projects will become increasingly important over the next years; opening your mind to these trends will open your door to new opportunities.

Project managers are increasingly asked to lead the organization in transformative ways. Since they often interact across the entire spectrum of departments within corporations, they are often exposed to emerging trends that other or departmental managers are not. Among the trends are an increased emphasis on project management soft skills, the Project Management Office (PMO) being viewed as a potential profit center (vs. a cost center), sustainability aggressively planned into projects, and an increased emphasis on corporate social responsibility.

Get it Now!  

Leave a Reply


7 × = forty two



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.

Sign up for our Newsletter

15,153 insiders are already enjoying weekly updates and complimentary whitepapers! Join them now to gain exclusive access to the latest news in the Java world, as well as insights about Android, Scala, Groovy and other related technologies.

As an extra bonus, by joining you will get our brand new e-books, published by Java Code Geeks and their JCG partners for your reading pleasure! Enter your info and stay on top of things,

  • Fresh trends
  • Cases and examples
  • Research and insights
  • Two complimentary e-books