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

I like the idea of aligning with JBDS version numbering. 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. Furthermore, since the platform cannot break compatibility in point releases, anything built against 4.2 should run just fine with 4.3. 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. 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). I think there's something to be said for being a release behind. That's just my opinion. Be gentle. ;) ----- 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 >