Community
Participate
Working Groups
Our "final" build before "lock down" had a surprising number of versioning errors. As far as I know, all of these need the service field incremented by 1. org.eclipse.jpt.eclipselink_sdk.feature 2.3.3.v201102072310-55584CACFnGjTEKECXQmNQPxChKAFBAWHdEGCB (current) 2.3.3.v201102072310-55584CACFnGjTEKECXQmNQPxChKA (reference) org.eclipse.jpt_sdk.feature 2.3.3.v201010220000-678590WCaKDHNT9-Ylef-xHxAmkE4xUhdWcnng1d (current) 2.3.3.v201010220000-678590WCaKDHNT9-Ylef-xHxAmkE (reference) org.eclipse.jsf.feature 3.2.3.v201101112207-7E7I7CF9JgLWPN-X2DIHK (current) 3.2.3.v201101112207-7E7I7BF9JgLWPMz0VyDEHH (reference) org.eclipse.jsf_sdk.feature 3.2.3.v201101112207-773584JAMBFJDNlQZZP9nCYSWbAKhMXQO0Y3EJIL (current) 3.2.3.v201101112207-773584JAMBEJDNlQZZP7HfHNSZTK (reference) org.eclipse.jst.jsf.apache.trinidad.tagsupport_sdk.feature 2.2.101.v20100906-53A98-5BdAz-F4B36DCj8x42322B28 (current) 2.2.101.v20100906-53A98-5BdAz-F4B36DCj8x42322B (reference) org.eclipse.jst.server_adapters.sdk.feature 3.2.2.v20100908-773-8-5BcAz-B6959A4B319_8x4232252A (current) 3.2.2.v20100908-773-8-5BcAz-B6959A4B319_8x42 (reference) org.eclipse.jst.webpageeditor_sdk.feature 2.3.2.v201101112207-55381B4DsE9CAAIBS4AC5ApC6976E9J3442 (current) 2.3.2.v201101112207-55381B4DsE9CAAIBS4AC5ApC6976 (reference) org.eclipse.jst.ws.axis2tools_sdk.feature 1.1.100.v201005241530-31A784D2JI3LdYHSJGgZcNCZmE_SELEEfQTLxIk (current) 1.1.100.v201005241530-31A784D2JI3LdYHSJGgZcNCZmE_S (reference) org.eclipse.jst.ws.jaxws.dom_sdk.feature 1.0.1.v201007112226-4--8z84HpKLJNEfKmDoDiBlG8C88OC_ChCh (current) 1.0.1.v201007112226-4--8z84HpKLJNEfKmDoDiBlG8C88 (reference) org.eclipse.wst.server_adapters.sdk.feature 3.2.0.v201005241510-773-826HsDnNCEkGLEUk2FpBlG88h9ICTd (current) 3.2.0.v201005241510-773-826HsDnNCEkGLEUk2FpBlG88 (reference) org.eclipse.wst.server_userdoc.feature 3.1.10.v201005241510-20DF7w312215222664 (current) 3.1.10.v201005241510-20Bg7w3121162A3236 (reference) org.eclipse.wst.xml_tests.feature 3.2.2.v201102160550-7D-G-BFAFkNZOOIftVGpA (current) 3.2.2.v201102160550-7D-G-AFAFkNZNPFfvWKpJ (reference) org.eclipse.wst.xsl_sdk.feature 1.1.3.v201101212242-528k98jYhYxz-WdHiZXZlQj3R98gq3xNW2OVE69y (current) 1.1.3.v201101212242-528k98jYhYxz-WdHiZXZlQj3R98g (reference)
In case there's any question, I'm giving this automatic "pmc approval" since I think _has_ to be fixed for release. Let me know if I'm seeing something wrong. I'm surprised some of these "changed" ... such as, I thought there were no bug fixes in JSF bundles. Anyone know why those qualifiers would change? Am I using the wrong reference?
(In reply to comment #1) > In case there's any question, I'm giving this automatic "pmc approval" since I > think _has_ to be fixed for release. Let me know if I'm seeing something wrong. > > I'm surprised some of these "changed" ... such as, I thought there were no bug > fixes in JSF bundles. Anyone know why those qualifiers would change? Am I using > the wrong reference? I'm not sure, but when I looked at the XSL and XML ones earlier, the tags are still the same. Would incrementing an EPP feature require us to increment? Did I already forget why the new qualifiers are longer, and thus automatically different, than the old ones?
> Did I already forget why the new qualifiers are longer, and thus automatically > different, than the old ones? Doubt you ever knew, but I forgot I made this change and that would explain some of it. The suffix-length issue is documented in bug 328900. In short, changed from 28 (default) to 38, since I was tired of the truncation problem making it appear as if a feature did not change. I think we do want to keep the longer ones, so even though "only a build change" I'd recommend the service fields be incremented, just to make sure there's no ambiguity. The reason I recommend we go with the longer ones, is that the suffix qualifier only grows to greater than 28, if it needs to, to maintain uniqueness with what ever bundles/features versions it is hashing. So all these are cases where a longer suffix was needed and we just never new it. Going with the shorter version will make it a bit more likely to run into hash collisions in the future. I'll now check to make sure the "directory length" is not getting excessively longer than in WTP 3.2.3, as described in bug 328900.
Oh, and meant to say, thanks for pointing out the "length" issue, Nitin. I was missing the tree due to the forest (or, something like that).
I think we are safe with the +10 feature suffix maximum. In WTP 3.2.3, we had one feature directory name above 100, it was 105. Now, with WTP 3.2.4, we have three above 100; 101, 103, 107. So ... we did increase maximum by 2 ... so, that could be debated ... but, still we are "under" the maximum in Helios SR2 as a whole, so doubt we'd run practical problems. Here is the "top" of the Helios SR2 distribution (feature directory names above 100): 100 2 101 3 102 5 104 1 105 2 109 1 112 1 So, in my opinion, we should stick with the +10 feature suffix, and increment these features, even though "merely a build change" ... not code.
I've incremented the service field for org.eclipse.jst.ws.jaxws.dom_sdk.feature and released the change.
Dali features have been updated to handle change in suffix length.
org.eclipse.wst.xml_tests.feature and org.eclipse.wst.xsl_sdk.feature incremented and released.
FYI, I've bumped the server adapters features org.eclipse.jst.server_adapters.sdk.feature org.eclipse.wst.server_adapters.sdk.feature I think, given the comments here, and the latest results, this will leave only the "jsf features" org.eclipse.jsf.feature org.eclipse.jsf_sdk.feature org.eclipse.jst.jsf.apache.trinidad.tagsupport_sdk.feature org.eclipse.jst.webpageeditor_sdk.feature and, a "new" one, that might be a ripple effect? org.eclipse.jst.ws.axis2tools_sdk.feature
I've bumped up the version for org.eclipse.jst.ws.axis2tools_sdk.feature.
looked good this week ... a few versioning errors remain, but they were unrelated to this build change, so new bugs will be open where needed.
New Gerrit change created: https://git.eclipse.org/r/109033
