classpath container, that kind of thing. the pom editor is nice to
have, but being without it means you can still use q4e and maven. so
achieving that goal.
I fully agree with your view Jake. If somebody is willing to be the "3.3
police" and make sure that we degrade gracefully, I'm all for it.
Right now, we need 3.4 for the xml databinding in pom editor, which is also
needed for making modifications to the pom.xml while keeping the original
format (if I've got this right), so it is becoming quite at the core of the
user experience. Mike can add more information in this specific case.
If we get the list of functionality that will work on 3.3 and it is of
value, we can document it and keep 3.4/3.5 extensions on separate plug-ins.
My impression is that it will be limited to core, jdt and wtp (not sure, I
think there are valuable enhancements on 3.4).
Anybody is willing to do this research?
--
El 27/11/2008, a las 21:04, Jake Pezaro escribió:
the biggest problem with having a minimum version requirement that it
close to the leading edge is that you will lose all those who cannot
upgrade. there are a lot of corporate users who are stuck on older
versions of eclipse, and do not have the freedom to upgrade at will.
if you set the minimum required version above what they can use they
will most likely switch to m2eclipse. once they have switched, it is
unlikely they will switch back unless something forces them to.
i would suggest supporting newer technology where it is available, but
degrading gracefully where it is not. the end result is that users on
older platforms will still be able to access core IAM functionality.
the example i am thinking of is eclipse's support for java 1.4, but
with a slightly reduced feature set which was enabled once the user
moved to 1.5
jake
I think I've echoed this before, but I'd aim for a stable release that
everyone can use, then roll onto the release train in future years. 3.4
users that don't want 3.5 should be happy with 1.0, 3.5 can use 1.1, etc.
3.4 at a minimum sounds pretty reasonable. The likely hinderances are the
slow adopters (like RAD?). It's probably something to trade off at the point
where compatibility is really holding back (like the examples you quoted).
Cheers,
Brett
On 27/11/2008, at 10:27 PM, Abel Muiño wrote:
Hello guys!
I've raised this topic a couple of times now, but I'll try to make this my
last :-)
I would like to push the minimum requirements of IAM to 3.4 (i'm tempted to
say 3.5).
Why:
We use dependencies from 3.4, backported for 3.3 (emf databinding): I would
happily change the maintenance and IP work for new feature development.
Some (most?) Eclipse projects target the current future release for its
dependencies (like emf). This means that we need to integrate with older
versions and don't get a chance to influence current development.
For example, PDE integration would probably need us to work with PDE in
order to define the extensions we will need. Also, P2 was not even available
in 3.3.
By the time we release 1.0.0, Eclipse 3.5 will be out.
I know that supporting 3.3 is good for increasing the number of users able
to run IAM, but our role as a technology project is to develop new
technology. After getting out of the incubator we can think about backwards
compatibility.
So, what is your opinion? Do you think we can support 3.3 at this time? (if
so, I want names! :-) ).
--
_______________________________________________
iam-dev mailing list
--
Brett Porter
_______________________________________________
iam-dev mailing list
_______________________________________________
iam-dev mailing list
_______________________________________________
iam-dev mailing list
