Re: [gef-dev] Gef Build questions

[Anthony Hunter <anthonyh@xxxxxxxxxx>]

Hi Ian,

I never saw your reply, so what do you feel needs to change.

As Nick says, "The current flow, as decided by Anthony...."

Currently, anything I commit will automatically be tagged, released, put in an integration build and the weekly integration build pushed to Eclipse.org. The only intervention needed is when you want to push Milestone and release builds (or run extra builds during the day when you cannot wait for the next build).

Cheers...
Anthony
--
Anthony Hunter mailto:anthonyh@xxxxxxxxxx
Software Development Manager: Eclipse Open Source Components
IBM Rational Software: Aurora / GEF / GMF / Modeling Tools
Phone: 613-270-4613


Nick Boldt ---05/08/2009 03:10:36 PM---Bundles are versioned based on x.y.z in Manifest.mf, and qualifier which comes from the mapfile. If

From:	Nick Boldt <nickboldt@xxxxxxxxx>
To:	GEF development <gef-dev@xxxxxxxxxxx>
Date:	05/08/2009 03:10 PM
Subject:	Re: [gef-dev] Gef Build questions

---

Bundles are versioned based on x.y.z in Manifest.mf, and qualifier which 
comes from the mapfile. If the o.e.gef plugin is tagged w/ version 
v20090508-1500, then you'll get

   o.e.gef_3.5.0.v20090508-1500.jar (note the dash).

If you want to be able to build from HEAD (override the tags in the 
map), you can use fetchTag=HEAD. In this case, you'll get

   o.e.gef_3.5.0.HEAD.jar (note the branch name).

But, if you also set forceContextQualifier=v${timestampOfTheBuild}, then 
you'll get

   o.e.gef_3.5.0.v200905081503.jar (note the dash is now gone)

This is doable, but I can't guarantee it works ATM in the Common 
Modeling Build. It does work in the Athena build, but doc generation is 
broken there. :( You can try setting these values in 
gef.releng/buildAll.xml if you'd like, but bear in mind such a change 
will affect both N and I builds.

You can follow whatever process you want for tagging or for building 
directly from HEAD. The current flow, as decided by Anthony, is to tag 
weekly so that all builds are done from that tag, and are therefore 
easily reproduceable. It also makes updating from week to week easier 
since the update site contains less renumbered jars.

Should you manually tag& release mid-week, your newer released changes 
will appear in that day's N build. Currently, the only difference 
between N and I builds is that Ns are not signed and Is are. 
Content-wise, they both pull from the same maps.

 > Does our auto tagging script only update the map file when things have
 > actually changed?  The reason I ask is because p2 only downloads things
 > that have changed, and it knows this by version numbers.  So if the
 > bundles in IBuild I and IBuild I+1 have the same version numbers, then
 > we know they have the same content, and p2 will not bother retrieving
 > the artifacts.
 >
 > Also, my understanding of tagging is that it is a way of indicating what
 > is ready for integration (difference between a nightly and integration
 > build).
 >
 > On the other hand, I understand that we are a small team and without
 > full-time releng support, the headaches with tagging + building may not
 > justify the benefits.


-- 
Nick Boldt :: http://wiki.eclipse.org/User:Nickb
Release Engineer :: Eclipse Modeling & Dash Athena
_______________________________________________
gef-dev mailing list
gef-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gef-dev