Does it make sense to keep trying to target a vanilla 3.5 install, so
that people who have CDT at the moment can take advantage of
ObjectivEClipse? Or do we want to forge ahead and keep up to date with
the latest CDT?
We have an outstanding bug that prevents the #imports working (http://code.google.com/p/objectiveclipse/issues/detail?id=21
) which is fixed in HEAD. It's something that we can live with, for a
while at least, but it will affect us once we've got the PDOM indexer
working since it won't be able to resolve things defined outside of
the #imports themselves. (Further down the line, this will also affect
code-completion).
My gut feel is that we should stay compatible with 3.5 as long as
possible and then break our dependency once we have so many (or so
critical) bugs that we have to upgrade. The alternative is to fork a
copy of CDT core to package as part of ObjectivEClipse in order to
take advantage of some of the bug fixes that get made. However, I'm
not sure whether it's a sustainable thing to keep going for the long
run, nor that people who would want to install ObjectivEClipse would
be happy with upgrading to a forked CDT.
Alex
> Do you have any stats on how many times the plugin has been
> downloaded? That would give a sense of our user base and how many
> people that decision would affect.
No, I don't. I think that Google Code has a tracker on the downloads
of the .zip, but it won't track those who have used the update site.
Chances are that there are few (and most are subscribed to this list)
but I feel for increasing adoption we should allow the Galileo/Eclipse
3.5 to be used as much as we can, since some won't want to update to
milestone builds for the sole purpose of trying out ObjectivEClipse.
Maybe we want to re-evaluate where we are later on in the 3.6 cycle,
but my concern is that the further it drifts, the more difficult it
will be to update later on. We thus lose the ability to test and get
bug fixes in for our needs should we find them.
Alex