*The [http://www.eclipse.org/webtools/releases/3.0.0/ 3.0 Release] pages should be reviewed by everyone to ensure accuracy. Information or screenshots in the New and Noteworthy may need updating, and there is a page for Release Notes. Good candidates for release notes include major fixes that were deferred to 3.0.1.

:The help has a file called "Limitations and Known Issues" - this functions as a type of readme so that users can easily search for problems that have known workarounds.

+

−

This will be kept in the help, team leads pls review current content and add anything extra

+

−

: Kate has opened a bug [https://bugs.eclipse.org/bugs/show_bug.cgi?id=233531 233531], please use to add updates using comments

+

−

+

−

=== Bug Lists to Ramp Down ===

+

−

+

−

:[https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&classification=WebTools&product=Dali+JPA+Tools&product=Java+Server+Faces&product=Web+Tools&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=blocker&bug_severity=critical&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=%7C%2C%2C All Blockers and Criticals] (~14)

:::In general, the minimum requirement is that if you branch a plug-in, you need to branch all the plug-ins in the corresponding map file. This is to make it easier for others to know what to load, to "be current" in a maintenance branch. It is fine to branch everything in a sub-project if you choose to, but still need to correspond to what's in a map file, and the map file should be updated to explain what it's used for. Map files can be re-organized some, if that helps make it easier to organize and understand what teams are working on what.

:::In general, the minimum requirement is that if you branch a plug-in, you need to branch all the plug-ins in the corresponding map file. This is to make it easier for others to know what to load, to "be current" in a maintenance branch. It is fine to branch everything in a sub-project if you choose to, but still need to correspond to what's in a map file, and the map file should be updated to explain what it's used for. Map files can be re-organized some, if that helps make it easier to organize and understand what teams are working on what.

:::The names for branches should follow the pattern of 'R3_0_maintenance'. This will be the name for all 3.0.x maintenance work (not just the first, 3.0.1 maintenance work). Note that JSF and JPA code may use R2_0_maintenance, but their map files, will still be branched using R3_0_maintenance.

:::The names for branches should follow the pattern of 'R3_0_maintenance'. This will be the name for all 3.0.x maintenance work (not just the first, 3.0.1 maintenance work). Note that JSF and JPA code may use R2_0_maintenance, but their map files, will still be branched using R3_0_maintenance.

WTP 3.0.1

Schedule

In general, the minimum requirement is that if you branch a plug-in, you need to branch all the plug-ins in the corresponding map file. This is to make it easier for others to know what to load, to "be current" in a maintenance branch. It is fine to branch everything in a sub-project if you choose to, but still need to correspond to what's in a map file, and the map file should be updated to explain what it's used for. Map files can be re-organized some, if that helps make it easier to organize and understand what teams are working on what.

The names for branches should follow the pattern of 'R3_0_maintenance'. This will be the name for all 3.0.x maintenance work (not just the first, 3.0.1 maintenance work). Note that JSF and JPA code may use R2_0_maintenance, but their map files, will still be branched using R3_0_maintenance.

References

In general, the minimum requirement is that if you branch a plug-in, you need to branch all the plug-ins in the corresponding map file. This is to make it easier for others to know what to load, to "be current" in a maintenance branch. It is fine to branch everything in a sub-project if you choose to, but still need to correspond to what's in a map file, and the map file should be updated to explain what it's used for. Map files can be re-organized some, if that helps make it easier to organize and understand what teams are working on what.

The names for branches should follow the pattern of 'R3_0_maintenance'. This will be the name for all 3.0.x maintenance work (not just the first, 3.0.1 maintenance work). Note that JSF and JPA code may use R2_0_maintenance, but their map files, will still be branched using R3_0_maintenance.

Instructions for tagging existing and new WTP wiki pages can be found at WTP's Category page; remember, we can create subcategories as well

Upcoming Focus Item

Past Focus Items

Invalid - Enhancement does not fit with the scope of the project or is already implemented.

helpwanted keyword - This is a valid request, but due to committer resources and other priorities, outside help will be needed to make this happen.

Future - I would use this in conjunction with the helpwanted keyword. I use this for legitimate requests that are important but will not make any planned release, but likely will make a future release.