Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 377312

Summary:	[pmi] Roll-up releases, plans, schedules, version numbers, and reviews
Product:	Community	Reporter:	Wayne Beaton <wayne.beaton>
Component:	Project Management & Portal	Assignee:	Portal Bugzilla Dummy Inbox <portal-inbox>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	mike.milinkovich
Version:	unspecified
Target Milestone:	---
Hardware:	PC
OS:	Linux
Whiteboard:
Bug Depends on:
Bug Blocks:	377310

Description Wayne Beaton

2012-04-20 15:52:36 EDT

We have several top- and mid-level projects that produce "roll-up" releases.

The Eclipse project, for example, produces a release that combines the top-level project with JDT, PDE, Platform, etc. Roll-up releases are not all-inclusive. The Eclipse project's roll up release does not, for example, include Orion. The combined release is given a single number (e.g. 3.8), is based on a single project plan, generates a single IP Log, and a single review document.

The Web Tools project is a little different. Included in the roll-up release is, among other projects, Dali. Dali actually has different release numbers than the parent project. It seems to conform to the same schedule as the parent, but has its own plan and new and noteworthy.

Section 4.2 of the EDP does state that "A Release may include the code from any subset of the Project's descendants.", but doesn't offer any more information than that.

The Eclipse Project's interpretation makes sense to me. If a project just wants to be a part of the parent project and release along side them, then they should be adopting/participating in the schedule, plan, and numbering. If a project wants its own schedule, version number, and plan, they should also do their own independent releases; they should participate as distinct entities in the simultaneous release.

Does this make sense? Are there any different opinions?

There is currently no formal means of describing these relationships. I intend to change that with the new Project Management Infrastructure (see Bug 377310).

[1] http://www.eclipse.org/projects/dev_process/development_process_2011.php#4_2_Code_and_Releases

Comment 1 Mike Milinkovich

2012-05-10 13:18:27 EDT

So you are saying that we would force Dali to adopt the same version numbering as the rest of the pieces of WTP it ships with?

If we're going to force projects to do something like that, could you explain why we (the EMO and the Eclipse community) care? What is the problem that we're trying to solve?

Comment 2 Wayne Beaton

2012-05-10 23:14:18 EDT

(In reply to comment #1)
> So you are saying that we would force Dali to adopt the same version numbering
> as the rest of the pieces of WTP it ships with?

I'm just asking questions at this point. I'm not so much worried about enforcing anything; I'm more concerned about supporting what we need to support in the project management infrastructure.
 
> If we're going to force projects to do something like that, could you explain
> why we (the EMO and the Eclipse community) care? What is the problem that we're
> trying to solve?

Primarily, it confuses me. What does it mean for Web Tools to ship 3.4 which includes Dali 3.2? We name our simultaneous releases because adding another number on top of the the big ball of version numbers from all the projects is confusing. If Dali has its own version number and plan, should it have its own release? Or, if Dali is releasing with it's parent project, should it be providing any release information of its own too?

Comment 3 Wayne Beaton

2014-02-13 13:01:24 EST

I'm going to declare victory.

The EDP already supports this notion.

The PMI has a feature where--as part of a release record--a project can indicate which of its subprojects are included in the release. I believe that the original concern of the bug is addressed.

A subproject can label their own bits with the version number that makes the most sense for the project. We have no specific requirement that project bundles, for example, have the same version number as the release. This may sound confusing, but it's been common practice to only rev bundle version numbers when the actual content in the bundle changes (this avoid unnecessary update requirements).

Further, this makes no assumption of how projects do their builds. Subprojects can potentially create their own builds that are picked up and distributed by the parent, for example. If a project is, however, producing their own downloads, with their own version numbers, on their own schedule, then they really aren't participating with the parent and should do their own independent releases.