> a) How and when do you usually
create the final downloadable zips and create the proper releases repository
The only practical approach is to rename
your zips and edit your download php or html files to change any URLs that
change as a result of that renaming (ideally such as using perl or sed
or something that can be automated).
Here is an example "rename"
script I use in Orbit project (which I probably copied from somewhere else
:) ... I'm sure there are better ones ... and this one should definitely
not be used "as is" ... I know first hand its easy to provide
wrong input arguments and "mess up" what you are trying to do
.... so, starting example only ... practice on your local machines before
> b) Do you use a new build
as explained above ? Do you use any moving/renaming technique from the
last RC build ?
Most I know just leave it as "RC1"
if there is no subsequent RCs ... ideally announcing on their project's
dev mailing list; which most consumers that depend on it would follow.
There has been times this is confusing and I know of one case a project
renamed their RC1 build to RC2, even though no changes. Others projects
I know try to avoid labels like "RC1" and just go with a date/time
stamp ... doesn't really solve the problem of good communication, but perhaps
leads to less miscommunication.
> c) Should I have any extra
consideration concerning the Helios aggregator build ?
Not really ... as long as your .b3aggrcon
file points to a valid repository. Some projects update to their final
repo (and the final URL in b3aggrcon file shortly before the "final"
common aggregation build, some do shortly after. Just make sure the final
repo is valid and that the aggregator gets exactly the same, specific,
determined features. I stress this last point since there are two ways
to have your b3aggrcon files so they are reproducible: a) features with
no versions specified, but repo used has only one version in it; b) repo
has more than one version, but b3aggrcon file spells out exactly which
version to use. (or, c) some projects do both :) So, as you move to "final",
make sure the b3aggrcon file has "completely determined" behavior
by what ever combination of feature version and repo specificity you use.
There's many twists, complications and
nuances to make things easier or harder, so be sure to ask or look at other
examples if things are not clear. For example, especially final repositories
should have a mirrorsURL attribute for their artifacts repo, they should
have "download stats" attributes, if desired .. and I'm sure
things I'm forgetting.
Hope I answered at least few of
your questions ... not sure I got them all :)
Adolfo Sanchez Barbudo
01/25/2011 03:51 PM
Trying to better understand/follow the process for the final Helios Service
As the release engineer of the MDT/OCL project I would
like to better understand some bits concerning the release engineering
in its final phase.
Last week we had Helios SR2 RC1. The steps were the following:
1. Run an M-build using the "3.0.2RC1" build
2. Publish the build so that
2.1 The downloadable zips are available
in our downloads web page
2.2 We provide what we call a maintenance
repository (http://download.eclipse.org/modeling/mdt/ocl/updates/maintenance/3.0.2/ )
with the proper content. It's a maintenance repository because it provides
an interim repository produced by our mainteance stream which could be
used by downstream projects (for their maintenance builds), or in this
case by the Helios aggregator build. First question here: could this maintenance
repository be associated/related to the sometimes heard (and unknown by
me) term of "staging" repository?
3. Configure our mdt-ocl.b3aggrcon file so that the helios
aggregator is feeded with our maintenance repository created by the M-build
All right so far. We have succesfully contributed MDT/OCL
3.0.2RC1 to Helios.
This week we have Helios SR2 RC2. As far as I have learnt,
I don't need to do a new build for the Helios SR2 RC since -in this case-
we don't have more changes comparing to the last SR2 RC1 build, so we are
right so far, aren't we ?.
Taking into account that we won't probably (and hopefully
;) ) have more changes to contribute to helios neither in RC3 or RC4 weeks,
it's supposed that the build we made last week (MDT/OCL 3.0.2RC1) should
suffice... It souunds good, however, I think that I'm missing something
else since we are not providing the proper downloadable zips in the web
page and the proper release repository with the final SR2. I believe that
at some point we should do -at least- something like the following:
So a lot of doubts here:
a) How and when do you usually create the final downloadable
zips and create the proper releases repository ?
b) Do you use a new build as explained above ? Do you
use any moving/renaming technique from the last RC build ?
c) Should I have any extra consideration concerning the
Helios aggregator build ?
Please, any correction to my exposition and specially
replies to the questions above will be very welcome.