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