Community
Participate
Working Groups
A few subtle changes in org.eclipse.wst.xml.xpath.core and org.eclipse.wst.xml.xpath.ui requires a version bump from 1.1.101 to 1.2, and a few additions of @since JavaDoc markers.
Which subtle changes? We're fast running out of time to do it if needed.
Created attachment 194232 [details] Patch to update versioning information for XPath plugins where needed Actually, I was going to wait to after the S build to submit this for PMC review, to not add noise, but here it is: The fix is to add "@since" tags on new elements since the Helios baseline. In the org.eclipse.wst.xsl.xpath.code bundle, a minor version bump was needed, which was reflected in the org.eclipse.wst.xsl.xpath.ui manifest file as well. In one instance, an API exception rule was appropropriate to not introduce deprecated code. * Explain why you believe this is a stop-ship defect. Or, if it is a "hotbug" (requested by an adopter) please document it as such. This updates the versioning information to the API tooling build is free of errors in the shipped code. Since this is also the API baseline for WTP 3.3 I'm thinking this is as important as the compiled code. * Is there a work-around? If so, why do you believe the work-around is insufficient? No work-around in the current tooling. * How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added? Local build of API tooling against Helios baseline reveals no errors. No JUnit test applicable. * Give a brief technical overview. Who has reviewed this fix? No review (yet) * What is the risk associated with this fix? The risk is very low, since only tooling and versioning information is changed. No actual run-time changes will occur.
Hi David, asking for review for the versioning tags.
Only thing missing is to make sure that the POM version numbers are updated as well if you are changing the plugin version.
PMC review information: * Explain why you believe this is a stop-ship defect. Or, if it is a "hotbug" (requested by an adopter) please document it as such. This updates the versioning information, so that the API tooling build is free of errors in the shipped code. Since this is also the API baseline for WTP 3.3, I think it is important to get right. * Is there a work-around? If so, why do you believe the work-around is insufficient? No work-around in the current tooling. * How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added? Local build of API tooling against Helios baseline reveals no errors. No JUnit test applicable. * Give a brief technical overview. Who has reviewed this fix? David Carver reviewed this. * What is the risk associated with this fix? The risk is very low, since only tooling and versioning information is changed. No actual run-time changes will occur, except for the minor version bump. If the review is successfull, I'll commit and release as soon as M7 is declared.
Which Milestone do you target this bug? M7 or RC1?
(In reply to comment #6) > Which Milestone do you target this bug? M7 or RC1? Targetting for RC1 (didn't see those in the dropdown when I filed)
Committed and released
