Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [dsdp-tcf-dev] Cutting a TCF Release for Helios

Let me know when it's tagged and I'll update the CDT build script to pick it up. Our last candidate build is tomorrow morning but we can respin until Monday if we have to.

Thanks!
Doug.

On Thu, Jun 3, 2010 at 1:58 PM, Tarassov, Eugene <eugene.tarassov@xxxxxxxxxxxxx> wrote:
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


From: dsdp-tcf-dev-bounces@xxxxxxxxxxx [mailto:dsdp-tcf-dev-bounces@xxxxxxxxxxx] On Behalf Of Oberhuber, Martin
Sent: Thursday, June 03, 2010 1:27 AM
To: DSDP TCF dev list
Subject: [dsdp-tcf-dev] Cutting a TCF Release for Helios
Importance: High

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?
  1. Right now, we have in SVN .../releases/0.2.0 which points to SVN version 836. This is our baseline from last year.
  2. 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.
  3. Ensure that all the legal files (abouts etc) are in place as needed - I can take care of that.
  4. When happy with everything, create a "releases/0.3.0" tag to point to your 0.3.0 version.
There's more nitty gritty involved, if you want to know all the gory details see http://wiki.eclipse.org/DSDP/TM/3.2_Release_Checklist ; but I think that for TCF we can be a bit more relaxed since it's still incubating.
 
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
 

_______________________________________________
dsdp-tcf-dev mailing list
dsdp-tcf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-tcf-dev



Back to the top