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

Tue May 29 12:55:53 EDT 2012

We can't afford to be a year behind, or even half a year behind like GWT 
was for the 3.7 stream. We need to be fairly tightly aligned w/ Eclipse 
and WTP because we are forever finding problems which if we wait a year 
to report, will NEVER be fixed. Eclipse does maintenance for exactly two 
releases after their June GA: September SR1, February SR2. Miss that 
window, and it's game over.

This is part of why we've now jumped on Juno in trunk even before Juno 
is released (last week of June).

As to minor releases being backwards-compatible, that's not always true 
and in fact was NOT true about 3.7 vs. 3.8/4.2.

We tried to make the current release of JBT/JBDS run on Juno, but it 
won't; which means we will be forced to have another release that's tied 
to a specific Eclipse/WTP release, this upcoming year too.

https://issues.jboss.org/browse/JBIDE-11549
https://issues.jboss.org/browse/JBIDE-11469

On 05/29/2012 12:35 PM, Rob Cernich wrote:
> 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>

-- 
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com