Jump to: navigation, search

WTP 2010-06-17

Revision as of 12:26, 17 June 2010 by David williams.acm.org (Talk | contribs) (WTP 3.2.1)

WTP Development Status Meeting


Project Leads
Eric X

Note: feel free to correct any errors/omissions in above attendance record.

Remember, any committer can add an agenda item. Typically, short announcements or news items go in the "Announcements" section at the beginning. Longer items or issues requiring discussion should go in the "Other business" section at end.

Announcements And Special Reports

WTP Calendar

(Weekly Google Calendar updated through June, 2010)

For Helios overall dates, see a Simultaneous Release Calendar

WTP 3.2.0

WTP 3.2 is done! ... almost:
Helios Release! 06/23
check "old help for new friends V" to see if anything needs to be added.
tag your released code with R3_2_0 (or R1_2_0 (JSDT), or R2_3_0 (Dali))
makes later comparisons easier ... but, tagged map files are the final authority (vS20100615235519)
The releng team
rename to "R" builds
prep and finalize repository (http://download.eclipse.org/webtools/repository/helios/)
prep for final downloads page (e.g. update prereq URLs)
Final N&N polish/links?
3.2 Announcement?

WTP 3.2.1

WTP 3.2.x maintenance release plan

builds have been set up and are running
recommend committers setup specific workspace for maintenance work, with final pde target runtime, etc.
be sure to use appropriate branch of map files
R3_2_maintenance (most)
R1_2_maintenance (JSDT)
R2_3_maintenance (Dali)
how/when to branch code?

In brief, while you are doing ONLY maintenance (so maintenance and "next major release" are exactly the same code) you can develop in only HEAD, but just be sure to release to the branched map files. You can merge (or "compare") HEAD map files with branched map files, so they have the exact same version tags in both map files ... that is, there is no need to "release" twice (should have exact same version and qualifier in both builds, if code is really exactly the same).

Remember to bump service field version ... normally +1, if destined for WTP 3.2.1, +100 only required if doing service for next major release, that will not be in a service release.

Once maintenance and "next major release" code streams start to differ, we have agreed, in the past, that code in the same map file, should all be branched together, at the same time, and comments in the map file updated. This makes it easier for others to "load up" an environment for what ever stream they are working on, where as if done bundle by bundle, no one can easily figure that out what's what.

  • Bug Review
Hotbugs [1]
Blocker and Critical
P1s that need attention

Other business

  • Next week's meeting (6/17) ... let's have our annual "debrief" meeting? See last year's notes. (Provide "input" to Planning council debrief meeting on 7/7).
  • I propose we still meet (briefly?) on 6/24, back to normal 7/1 (our first declared M build)
  • WTP 3.2 release maintenance
Started release plan document
Simultaneous Maintenance (Helios SR1, SR2) is a given (requirement)
Those are fourth Friday of September and February
Proposal for other off-cycle maintenance? WTP 3.2.1 end of July?
given schedules of some adopter testing, it is anticipated several fixes for adopter scenarios will be desired during June.
Appears broad enough interest to propose WTP-wide maintenance (instead of specific sub-projects).
continue "controlled mode" for duration (since very short)
Project lead review and approval until July 1
PMC 1 review: July 2 - July 8
PMC 2 review: July 9 - July 15
PMC 3 review: July 16 - July 22
Release: July 30
Builds start approximately mid June
Weekly testing and declared builds during July
Our WTP repository would be updated, but not the common Helios repo or EPP packages (until SR1, WTP 3.2.2).
This is similar to what we did for WTP 3.0
  • Migrate Incubator projects to Git - http://dev.eclipse.org/mhonarc/lists/wtp-incubator-dev/msg01209.html (Dave Carver)
    • Estimated Time Frame: July after WTP 3.2 is out.
    • All active Incubator components/projects have agreed.
    • XML Security, XQuery, Vex, RelaxNG.
    • Allows for a lower risk area for Web Tools projects to get lessons learned for any other project migration.
    • Allows for updating any existing releng projects and processes to take advantage of git, or re-architect existing processes if necessary.
    • Allows for active feedback to eGit project on use of their plugin to help improve it for the entire eclipse community.


  1. Hotbug Policy

Also, see


Web Tools Platform Plans

IP Logs selector

WTP 3.1 Post Mortem

See also the WTP Meeting Archive-Reference Page.