4:53 a.m.
Hi everyone
Just a quick note on SOA tooling development. Now that JBT and JBDS have been branched for
CR1 trunk will move over to Juno development; so all further development of the SOA
Tooling will need to be done on the CR1 branches.
For SOA tools development that would be
http://svn.jboss.org/repos/jbosstools/branches/jbosstools-3.3.x
For SOA studio development that would be
https://svn.jboss.org/repos/devstudio/branches/devstudio-5.0.x
Fixes should also be committed to trunk for inclusion in versions 3.4 and 6.0
respectively.
Regards
Doug
Douglas Palmer
dpalmer(a)redhat.com
JBoss, by Red Hat
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham (USA), Mark Hegarty (Ireland), Matt Parson
(USA), Charlie Peters (USA)
10:59 a.m.
New subject: What should we call next year's JBoss Tools release? :: JBDS-1987
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
11:35 a.m.
New subject: 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
11:55 a.m.
New subject: What should we call next year's JBoss Tools release? :: JBDS-1987
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(a)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
4:05 a.m.
New subject: [Soa-tools-list] What should we call next year's JBoss Tools release? :: JBDS-1987
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
4:11 a.m.
New subject: [Soa-tools-list] What should we call next year's JBoss Tools release? :: JBDS-1987
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
10:31 a.m.
New subject: [Soa-tools-list] What should we call next year's JBoss Tools release? :: JBDS-1987
Having thought about this some more, my favourite versioning scheme
going forward is this:
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
In this scenario:
* minor digit of JBT (.6) ==
* major digit of JBDS (6.) ==
* sum of major (4) + minor (2) digits of the Eclipse version (4.2).
Also, the JBT component with the largest version (Hibernate Tools 3.6)
will match the overall version (JBoss Tools 3.6), for an extra level of
synchronicity.
(If we continue with the current scheme, calling next year's release
3.4, we will continue to have Hibernate Tools at a version greater than
the overall release (3.6 > 3.4), which IMHO seems a bit odd.
---
So say we all? I'd like to upversion all the jobs which currently say
"3.3_trunk" and fix the JBIDE targets (3.4.* -> 3.6.*) if we're going to
use 3.6 instead of 3.4 for our Juno-based release.
Nick
On 05/30/2012 05:11 AM, Max Rydahl Andersen wrote:
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
--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com
4525
days inactive
4561
days old
jbosstools-dev@lists.jboss.org
6 comments
4 participants
participants (4)
-
Doug Palmer -
Max Rydahl Andersen -
Nick Boldt -
Rob Cernich