It is too late for SR2, for several reasons, but a great suggestion for Kepler, if the TM project (or others) want it.
Just to briefly outline the reasons, we are already up to RC2 and RC3, so I think it'd have to be a "blocking problem" to cause all that stress, and it doesn't sound like a blocking problem, from what I've heard. I don't know who else uses it, but typically it's only reasonable to give the "community" of projects and adopters a minimum of a month, or two, notice of what's coming in a maintenance release, especially if it involves a "major" version change [And, I mean a month or two before the first release candidate, not the "GA date"]. We in Orbit do have a generic "ramp down" process for the purpose of stability, so it'd have to be a pretty strong case. But, if you and the TM project think it is a blocking problem, and worth the churn, feel free to open bugs, CQs, etc., and continue to make your case. I'm just giving you my impression from the little I know. [I would say it would have been a good suggestion a month or two ago, but not sure when 3.2 was released, since the date on their web site says "TBA" (even though it appears to be available for download), so, maybe just released?] And, Kepler is not that far away. I don't recall seeing the "CQ deadline" for Kepler officially announced recently by the Eclipse Foundation, but its typically "M5" which is just a couple of weeks away (February 8). (Its not that they can not be submitted after that, but those submitted by the M5 deadline allows for proper planning, etc. and thus given higher priority, all else being equal). But, I'm not specking for the Eclipse Foundation ... I hope they weren't waiting for me :) .... just saying what it has been in the past several yearly releases. This is probably not a very constructive reply (and not what you wanted to hear) ... but, I do think we need to focus on stability for Juno, and new things for Kepler. Thanks for bringing it up, though. From: Stephan Leicht Vogt <stephan.lei...@bsiag.com> To: "cross-project-issues-dev@eclipse.org" <cross-project-issues-dev@eclipse.org>, Date: 01/29/2013 01:51 AM Subject: Re: [cross-project-issues-dev] Heads up ... new "Recommended" Orbit repo for Juno SR2 Sent by: cross-project-issues-dev-boun...@eclipse.org Hi Some text went missing in the last mail. At least a: Greetings Stephan --- Stephan Leicht Vogt Senior Software Engineer BSI Business Systems Integration AG Täfernstrasse 16a, CH-5405 Baden Phone (direct): +41 56 484 19 47 www.bsiag.com On Jan 29, 2013, at 6:48 AM, Stephan Leicht Vogt <stephan.lei...@bsiag.com > wrote: Hi all Wouldn't it be better in this situation to pack the newest Version 3.2 from commons net to Orbit. Even if this comes up a little late and the R Version of Orbit is already promoted for Juno SR2. As Apache has released 3.2 this would be IMHO the better way than to pack an version which is two years old into the EPP. I would do the update but David Dykstal would have to open a (high prio?) CQ from the TM Project to use Apache Commons Net 3.2 so Orbit could open a piggyback. What do you think? Or From: "Oberhuber, Martin" <Martin.Oberhuber@xxxxxxxxxxxxx> Date: Thu, 24 Jan 2013 18:30:34 +0000 Accept-language: en-US Delivered-to: cross-project-issues-dev@eclipse.org Thread-index: AQHN+leHmRtU+ONw4kCQt/T6cQwZMJhZRdgAgAAH+ID//34PkA== Thread-topic: [cross-project-issues-dev] Heads up ... new "Recommended" Orbit repo for Juno SR2 Hi David (and all), We only want a build-time selection of Commons Net 2.2 from Orbit. The MANIFEST.MF at runtime should be open to allow [2.2,4.0) or even higher (as per the recent ICU4J discussion). The reason for picking 2.2 by default is that it’s known to work safely whereas 3.1 can produce a deadlock in some situations with Telnet. End users should be able to deploy 3.2 (which is not in Orbit yet) or 3.1 (if they are not affected by the deadlock situation). Does anybody know how to enforce a particular bundle version install at build time with Maven ? Thanks, Martin --- Stephan Leicht Vogt Senior Software Engineer BSI Business Systems Integration AG Täfernstrasse 16a, CH-5405 Baden Phone (direct): +41 56 484 19 47 www.bsiag.com [attachment "smime.p7s" deleted by David M Williams/Raleigh/IBM] _______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
