Re: [jbosstools-dev] [Soa-tools-list] What should we call next year's JBoss Tools release? :: JBDS-1987

2012: JBT 3.3 / JBDS 5.0 / Eclipse 3.7 Indigo 2013: JBT 3.6 / JBDS 6.0 / Eclipse 4.2 Juno 2014: JBT 3.7 / JBDS 7.0 / Eclipse 4.3 Kepler

p.s. just removed all the internal lists from this thread since its a jbosstools question. /max On May 30, 2012, at 11:05 , Max Rydahl Andersen wrote: > > On May 29, 2012, at 18:35 , Rob Cernich wrote: > >> I like the idea of aligning with JBDS version numbering. > > I don't like that - the binding is inverse of what is actually happening. JBoss tools goes into JBDS not the other way around. >> >> I question why we need to track the Eclipse release train. I'll admit I don't understand the exact implications with respect to JBT/JBDS, but many projects (e.g. m2e, wtp, etc.) are backward compatible with the core platform (the SwitchYard tooling is compatible with 3.6 and 3.7). If we're simply doing this to keep up with the latest version of Eclipse, while I think that's admirable, I would ask if it's actually necessary. > > Examples of why we tend to move with Eclipse release train: > > WTP text editors changes between major versions. > > Dali JPA breaks ever year - no way for a compatible release. > > You can't run Oracle Java 7 on OSX with Eclipse 3.7, only Eclipse 3.8 > > only Eclipse 3.8 has fixes that makes Eclipse actually run on 64-bit windows/linux reliably. > > bugfixes only goes into the latest eclipse release train. > > Some plugins can easily run across multiple versions - others just can't. > >> Furthermore, since the platform cannot break compatibility in point releases, anything built against 4.2 should run just fine with 4.3. > > Yes, that is though not true in reality unless you strictly conform to using fully public API - and in even in those cases we have found subtle issues that breaks between point releases. > >> That said, there's nothing that prevents the user from updating their install, which would move them from 4.2 to 4.3 independently of whatever we do. At that point, I guess it really becomes a support question. >> >> I also think there are arguments for not being on the bleeding edge. > > It's not really about bleeding edge, its that bugs and features we rely on to move forward is not available nor will be fixed in older eclipse versions. > >> For example, the GWT plugins were available for 3.7 for a good period of time, which caused problems if you needed to use 3.7 for other development. This basically forced me to have two development environments (3.6 and 3.7) until the GWT plugins were stable enough on 3.7 (though still using a nightly). > > Yes, Google are horrible at these things - they also changed plugin ids between minor version updates at some point. > >> I think there's something to be said for being a release behind. > > Yes, which we actually are. We are a release behind with JBoss Tools 3.3.x. > >> That's just my opinion. Be gentle. ;) > > I wished for the next rev of jboss tools to target both Eclipse 3.7 and 3.8/4.2 but Dali/JPA prevents that currently - and we'll probably find more issues. > > I'm open for suggeestions on how we can handle these without massive maintenance burden. > > btw. fyi: historically it looks like>50% of our users move upto the newest version of eclipse within a few months its release (assuming we actually have a release out that works with it) > > /max > > >> >> ----- Original Message ----- >>> Just FYI, there's been some discussion about the next release of JBT >>> in >>> terms of its actual version number. >>> >>> I set 3.4 for next year's 2013 release because it's the next logical >>> version and continues to follow the Web Tools project @ Eclipse for >>> base >>> version numbering. >>> >>> --- >>> >>> HOWEVER, it's been suggested we might want to align w/ Eclipse this >>> time >>> around to emphasize the fact that the next release will build on top >>> of >>> the 4.x series of Eclipse platforms, rather than the 3.x series (JBDS >>> 5 >>> uses Eclipse "Indigo" 3.7.2, but JBDS 6 will use Eclipse "Juno" 4.2 >>> which has a compatibility layer so it can run on 3.8.). >>> >>> So, we could call the next JBT 4.0 or 4.2 (or stick with 3.4): >>> >>> 2012: JBT 3.3 / JBDS 5.0 / Eclipse 3.7 >>> 2013: JBT 4.0 / JBDS 6.0 / Eclipse 4.2 >>> 2014: JBT 4.1 / JBDS 7.0 / Eclipse 4.3 >>> >>> OR >>> >>> 2012: JBT 3.3 / JBDS 5.0 / Eclipse 3.7 >>> 2013: JBT 4.2 / JBDS 6.0 / Eclipse 4.2 >>> 2014: JBT 4.3 / JBDS 7.0 / Eclipse 4.3 >>> >>> --- >>> >>> There's also an open JIRA asking that the next release of JBT be >>> called >>> 6.0 to finally align with JBDS. So JBT 6 would feed JBDS 6, instead >>> of >>> JBT 3.4 feeding JBDS 6.0. Simpler, no? >>> >>> The only snag with the 6 -> 6 plan is that it means the year after, >>> we >>> might want to do a minor update, JBT 6.1 based on Kepler (Eclipse >>> 4.3), >>> but because we can't do a platform upgrade from an Eclipse 4.x to >>> 4.(x+1), we need to call the following year's release JBDS 7, not >>> 6.1, >>> and that breaks the numbering alignment again. >>> >>> Conversely, if we call the 2014 release JBT 7 and JBDS 7, we are >>> implying a huge API change from the 2013 release. This isn't the end >>> of >>> the world, but may in fact prevent adoption as people will see 7 as >>> being a major break from 6, vs. simply having a 6.0 then 6.1 minor >>> release: >>> >>> 2012: JBT 3.3 / JBDS 5.0 / Eclipse 3.7 >>> 2013: JBT 6.0 / JBDS 6.0 / Eclipse 4.2 >>> 2014: JBT 6.1 / JBDS 7.0 / Eclipse 4.3 >>> >>> or >>> >>> 2012: JBT 3.3 / JBDS 5.0 / Eclipse 3.7 >>> 2013: JBT 6.0 / JBDS 6.0 / Eclipse 4.2 >>> 2014: JBT 7.0 / JBDS 7.0 / Eclipse 4.3 >>> >>> --- >>> >>> Here's another option, which I like though it reminds me a little of >>> how >>> Sun used to do version numbering (drop first digit between >>> releases*): >>> >>> 2012: JBT 3.3 / JBDS 5.0 / Eclipse 3.7 >>> 2013: JBT 3.6 / JBDS 6.0 / Eclipse 4.2 >>> 2014: JBT 3.7 / JBDS 7.0 / Eclipse 4.3 >>> >>> In this scenario, the minor digit of JBT == major digit of JBDS = sum >>> of >>> major + minor digits of the Eclipse version. Clarity w/o parity. :) >>> >>> --- >>> >>> Please discuss your preferences in >>> https://issues.jboss.org/browse/JBDS-1987. >>> >>> -- >>> Nick Boldt :: JBoss by Red Hat >>> Productization Lead :: JBoss Tools& Dev Studio >>> http://nick.divbyzero.com >>> >>> * - >>> http://en.wikipedia.org/wiki/Solaris_%28operating_system%29#Version_history, >>> http://en.wikipedia.org/wiki/Java_version_history >>> _______________________________________________ >>> jbosstools-dev mailing list >>> jbosstools-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >>> >> >> _______________________________________________ >> Soa-tools-list mailing list >> Soa-tools-list(a)redhat.com >> https://www.redhat.com/mailman/listinfo/soa-tools-list > > _______________________________________________ jbosstools-dev mailing list jbosstools-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev