Many thanks, Eugene! This looks good over
all.
I have a couple questions:
-
In o.e.tm.tcf/MANIFEST.MF, why don't you put a version=0.3.0
on Export-Package:
org.eclipse.tm.tcf.extensions?
-
Some
exported internal packages in tm.tcf.debug/META-INF/MANIFEST.MF are lacking
the "x-internal:=true" or "x-friends:=" directive. As a result, clients may
think this is public API. This is dangerous and should be fixed. See also the
Eclipse Guideline: http://wiki.eclipse.org/Export-Package -
you can use PDE TOols > Organize Manifests to automate the
process.
-
I did
not exactly understand why you also reved up the version on tm.tcf.dsf -- my
understanding is that the two DSF plugins are really dead code, nothing has
happened to them in the past year, they don't even compile since DSF was moved
into the CDT ?
-
In
plugin.properties, the providerName should be "Eclipse.org - DSDP" for
consistency, and as required by the Development Process. Same in
feature.properties.
Would it be possible to re-do the .../tags/0.3.0 with these
changes?
Thanks,
--
Martin Oberhuber, Senior Member of Technical
Staff, Wind River
direct
+43.662.457915.85 fax +43.662.457915.6
I have created .../tags/0.3.0 out of revision
994
Regards,
Eugene
Ok,
.../tags/0.3.0 sounds fine to me.
My other comments about 0.2.100 etc were about individual
bundle versions. But arguably there is not much value on investing time into
specific bundle versions ... so I'm fine if they are all at
0.3.0.
FYI, the TM Hudson builder now also builds TCF, so we can have
.ZIP downloads as well as a TCF update site:
Thanks,
--
Martin Oberhuber, Senior Member of Technical
Staff, Wind River
direct
+43.662.457915.85 fax +43.662.457915.6
Hi Martin,
OK, lets do it.
BTW, .../releases directory was created for pre-build code.
.../releases/0.2.0 is an update site:
which contains all binaries, including pre-built agents for
Windows and Linux, but no source code.
Essentially, it is a P2 repository of pre-built TCF
SDK.
It was created for testing and needs more work to be
usable - I would appreciate any feedback.
According to SVN conventions, we should use .../tags directory
to tag source code.
I think we should use version 0.3.0, because we have both new
APIs and new features.
Regards,
Eugene
Hi
all,
I think that a
formal release of TCF should be cut for Helios in the SVN
Repository.
Reasons
include:
- TCF is being
delivered as part of CDT 7.0, so it *is* being released, no matter what is
done to the Repository.
- Because of being
released, TCF must provide an IP Log and Release Review Slides (I have taken
care of that by including TCF in the TM slides and IP Log, since TM is the
container of TCF).
- It is good for our
communities to have a formal milestone in terms of API changes, such that
people know what has been changed in this year compared to last year
etc.
So - what is
involved in cutting a formal TCF release?
- Right now, we have
in SVN .../releases/0.2.0 which points to SVN version 836. This is our
baseline from last year.
- Increase
the bundle and feature versions to "0.3.0" or "0.2.100" as
appropriate. Keep at "0.2.0" when absolutely nothing was changed; use
"0.2.100" when only minor implementation changes occurred; use "0.3.0" when
API was added or new features were added compared to the "0.2.0"
state.
- Ensure that all the
legal files (abouts etc) are in place as needed - I can take care of
that.
- When happy with
everything, create a "releases/0.3.0" tag to point to your 0.3.0
version.
As mentioned, I can
take care of (3) but I need YOU as the TCF committers / contributors to handle
(2) and (4). Make sure that TCF is in a "stable" state when creating the 0.3.0
tag (well, as far as I know TCF is always stable).
Many thanks for your
help;
Please let me know
if there are any questions.
Thanks,
--
Martin Oberhuber, Senior Member of Technical
Staff, Wind River
direct
+43.662.457915.85 fax +43.662.457915.6