Hi all,

 

TM 3.4rc1 is released. It includes the new Commons Net bundle, as well as a couple bug fixes.

http://eclipse.org/tm/

 

Committers, remember that as per our ramp-down plan we’ll need an additional review+ on every fix from now on.

http://wiki.eclipse.org/TM/3.4_Ramp_down_Plan

 

I’d love to be done by RC2 this year, so can you please identify any bugs that you plan to still fix and move out the target milestone for others.

At the moment, I see 20 bugs … that seems too much for me:

http://bit.ly/K9scrD

 

Please review and move out yours.

 

Thanks,

Martin

--

Martin Oberhuber, SMTS / Product Architect – Development Tools, Wind River

direct +43.662.457915.85  fax +43.662.457915.6

 

TM committers,

 

I have released TM 3.4M7 and contributed to Juno:

 

http://download.eclipse.org/tm/downloads/drops/S-3.4M7-201205071515/index.php

 

http://download.eclipse.org/tm/updates/3.4milestones

 

Some notes:

-          As discussed on our monthly call, this is built from “nightlies” without a Mapfile.

-          Moving forward, you can use N-builds. This is in preparation of the move to git / Tycho.

-          I have still also released to the Mapfile but this is not planned to be used.

-          All (micro / minor) versions have been updated in order to accommodate the new pom.xml files for Tycho.

-          I have created “RC1-3” target milestones in Bugzilla.

 

Towards the 3.4 release, please consider our http://wiki.eclipse.org/TM/3.4_Ramp_down_Plan

 

I noticed that bugzilla still has lots of old bugs assigned to old target milestones. Please clean up.

 

Let me know if there are any questions.

 

Thanks,

Martin

--

Martin Oberhuber, SMTS / Product Architect – Development Tools, Wind River

direct +43.662.457915.85  fax +43.662.457915.6

 

FYI â below is the Eclipse Platformâs approach towards getting an equivalent for the Mapfiles in Tycho.

Itâs still work in progress apparently but it is coming up.

 

Martin

 

From: eclipse-dev-bounces@xxxxxxxxxxx [mailto:eclipse-dev-bounces@xxxxxxxxxxx] On Behalf Of Paul Webster
Sent: Wednesday, April 04, 2012 4:22 PM
To: General development mailing list of the Eclipse project.
Subject: Re: [eclipse-dev] Planning Meeting Notes - 4 April 2012

 

CBI Update:

CBI is a further investment by the Eclipse Foundation in a common build infrastructure.  The primary driving usecase right now is to be able to build the Eclipse Project using CBI (maven, tycho, foundation signing, hudson to drive the builds and tests, etc), in preparation for their Long Term Support [1] initiative.

The Roadmap [2] describes the main issues CBI is working through and its current timetable.  There's a code sprint next week in Ottawa [3] to get people together to complete some tasks.

[1] http://wiki.eclipse.org/LTS

[2] http://wiki.eclipse.org/CBI/Eclipse_Platform_Build_Roadmap

[3] http://wiki.eclipse.org/CBI/Code_Sprint_April_11_2012


Discussion Topic: CBI initiative and build qualifiers

One of the requirements is that we get reproducible build qualifiers for our plugins and features.
Bug 370707 - reproducible build version qualifiers
Bug 367581 - do not generate new version qualifier unless there are actual code changes

Currently the proposal (after discussion with Kim, John, and myself) is https://bugs.eclipse.org/bugs/show_bug.cgi?id=367581#c13

----
here is the outline of required changes

* Introduce extension point in Tycho BuildQualifierMojo that will allow custom

logic to determine build timestamp.

* Implement jgit-based implementation of the extension point from the item

above that will use project last commit's timestamp as the build timestamp.

* Embed project last commit's timestamp either in project jar file or p2

metadata. This will be used to calculate feature version qualifier (see below).

* For bundle projects, version qualifier will be rendered from the build

timestamp using existing Tycho formatting configuration.

* For feature projects, build timestamp is selected is the latest timestamp of

the feature project itself and any features/bundles included in the feature.

* Implement new Tycho goal that will compared bundle and feature jars to a

baseline version and fail the build if new and baseline version have the equal

version but different contents. When this happens, developers are expected to

make artificial changes to changed projects to force new version qualifier.
---- 

It is taking the same approach we currently using in our auto-tagging, which is to derive the qualifier as the UTC timestamp of the last commit to touch that plugin or feature.

Discussion topic: The implication of this is that all of the bundles in 3.8/4.2 would have their qualifier bumped, even if they haven't changed in 3.8, to switch to qualifiers entirely derived from the source for that bundle.  From that point on, the qualifier would be derived from the source.  Our current auto-tagging derives the qualifier the same way (but feeds that information into the map files).

I did a quick check.  The only bundles that are the same between 3.7.0 and 3.8 M6 are:
org.eclipse.core.boot_3.1.200.

--
Paul Webster
Hi floor.  Make me a sammich! - GIR

Hi all,

 

Notes of the meeting we just had are now available:

http://wiki.eclipse.org/TM/Meetings/4-Apr-2012

 

 

Thanks,

Martin

--

Martin Oberhuber, SMTS / Product Architect – Development Tools, Wind River

direct +43.662.457915.85  fax +43.662.457915.6