Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Trying to better understand/follow the process for the final Helios Service Release.

> 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).

This was discussed in the past, and here is a link to at least one of the messages in the thread:
http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg04586.html

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 production use:
http://download.eclipse.org/tools/orbit/committers/renameBuild.sh


> 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 :)







From:        Adolfo Sanchez Barbudo <adolfosbh@xxxxxxxxxxxxxxxx>
To:        cross-project-issues-dev@xxxxxxxxxxx
Date:        01/25/2011 03:51 PM
Subject:        [cross-project-issues-dev] Trying to better understand/follow the process for the final Helios Service Release.
Sent by:        cross-project-issues-dev-bounces@xxxxxxxxxxx




Hello Folks,

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 alias.
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 mentioned above.

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:

1. Run an R-build using "3.0.2" build alias.
2. Publish the build so that
     2.1. The final downloadable zips are avaiable in our downloads web page.
     2.2. We provide our public releases repository (http://download.eclipse.org/modeling/mdt/ocl/updates/releases/3.0.2/ with the proper content.

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.

Best Regards,
Adolfo._______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


Back to the top