Skip to main content

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

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 ( ) 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 ( 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,

Back to the top