>> (Btw: if anybody uses FreeBSD, what
>> is the state of Java 5 support there?)
> It would be a very good idea to ask that on a Java or FreeBSD
> discussion group. But I would bet that after 1,5 year it is already
> stable. I could be wrong, of course.
With FreeBSD in particular there were licensing issues, I remember, when
I looked at it half a year ago. I would be interested if someone
actually uses Eclipse with Java 5 on FreeBSD. But that's just my
curiosity, the main platforms that we target with eclipsefp are Windows,
Linux and MacOS X.
>> Well, I agree to a certain degree. The most important thing for me is to
>> code with the 3.2 JDT/PDE (because of the improved coding support).
>> But there is a couple of issues there (I have been constantly using the
>> latest milestones against the last releases in customer projects, and my
>> experience was mixed with such a scenario). Especially if some
>> developers use 3.1.x and some use 3.2, the compiler settings files etc.
>> are constantly screwed up.
> I have happened to see that, and it is not very nice to deal with
> those issues (although not impossible).
> There are two issues here. The first is the choice among our users to
> have a mix of Eclipse platforms on their environment. The second is
> _our_ decision to use different platforms. I think the second issue is
> very easy to solve, we just need to agree on a platform version for us
> to use on the development of EclipseFP. The first one is a slightly
> more difficult issue, maybe we should warn our users (somewhere on our
> website) that there are such compatibility issues and to advise them
> to choose a unique platform to work with.
> I would agree that we can switch our environment to 3.2 already (I am
> actually already doing it to some extent).
Yes, I'm doing that too. Then the proposal is:
For eclipsefp development:
- Eclipse 3.2 as development IDE,
- Eclipse 3.1.x as target platform (although with an eye on 3.2
- Java 5 - code (i.e. generics allowed)
For eclipsefp users:
- Eclipse 3.1.x and Java 5 runtime, but
- Eclipse 3.2 and Java 5 runtime has also a good chance to work (see below).
>> The thing is: the milestones are called 'Stable builds' (as compared to
>> release builds) and they actually are very stable. Sometimes they may
>> have nasty little bugs, but I have never seen one that prevented me from
>> working with it. Therefore, most developers that I know use the 3.2
>> milestones. Companies that build upon the platform normally go with the
>> releases, because of the API stability (API changes throughout the cycle
>> require adjustments every time, so they'd rather do this only once a
>> year after the final release.) But developers would rather have all the
>> new features earlier. So that's the reason I'm asking around: if anybody
>> works on 3.1 anymore and would have to go through a major hassle, I'd go
>> the extra mile and keep compatibility. But if everybody is gladly
>> hacking away with 3.2 anyway, then why bother with the old stuff? :-)
> Very well said. But I am concerned with new users we might get too.
> Maybe a new Eclipse adopter (we can even think of someone that
> downloaded Eclipse just in order to use FP) won't be as open to using
> a development version of the platform as the old-timers (that know
> that _those_ particular version are _indeed_ very stable). Eclipse.org
> itself encourages newcomers to download and install the latest
> release. The downloads page has a huge link for platform 3.1.1 and a
> tiny link to 3.2M4. The 3.1.1 version is in fact the most downloaded
> Maybe I am underestimating, but I don't think maintaining backwards
> compatibility will be a big issue. I think we can get going until June
Right. I'm not religious about that issue, and the point about newcoming
users is valid. So let's say we do our best and try to support both
versions, and should we get into a situation where we really break
compatibility, then we can re-discuss :-)