Hi,

For now we rely only on the current operations provided by Iceberg. The good part is that we could use them to build a release tool. We are still missing some operations that would make releaser more resilient. Now we get releases that fail because of the way we use Iceberg.

In short we use a dedicated release branch and we need to merge the master branch into the release branch. Now we checkout the release branch explicitly which changes the image code causing all sorts of troubles. For example, we cannot really create releases for the releaser project using releaser, as the running code can change during the release. Also releasing Bloc using a UI based on bloc does not work well.

What we are currently missing is to be able to configure a merge with a conflict resolution and checkout strategy. Then we could have merges that do not load code. There is another thread discussing this [1]

What would also be useful is to have more operations at the libgit level. For example, not sure how to use libgit now to make a merge. That would make it possible to experiment with other ways of doing a release, like just using low level libgit operations without changing any code in the image.

Cheers,
Andrei

[1] http://forum.world.st/iceberg-merging-branches-just-at-the-git-level-without-changing-code-in-the-image-td5094770.html


On Thu, Feb 21, 2019 at 8:34 AM Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Sounds cool. 
Now since you reify git action. Did you need ones that are not defined in iceberg. 

Stef

On 19 Feb 2019, at 10:38, Tudor Girba <tudor@tudorgirba.com> wrote:

Hi,

Andrei wrote a post describing GT Releaser:
https://medium.com/feenk/continuous-delivery-with-gt-releaser-4fc6c30e1f33

We use it for releasing reliably GT. GT is spread throughout multiple repositories and have deep dependencies, and yet we release it on every commit in a reliable fashion, while still allowing people to load small pieces independently from the overall GT. For example, people can load GT Examples, or GT Releaser independently. Another thing is that we also handle the dependencies to external projects, such as SmaCC.

The same can be applied for Moose. Would you like to look into this opportunities to make Moose more modular and friendlier to outside projects?

Cheers,
Doru

--
www.feenk.com

"No matter how many recipes we know, we still value a chef."








_______________________________________________
Moose-dev mailing list
Moose-dev@list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev

--------------------------------------------
Stéphane Ducasse
03 59 35 87 52
Assistant: Julie Jonas 
FAX 03 59 57 78 50
TEL 03 59 35 86 16
S. Ducasse - Inria
40, avenue Halley, 
Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
Villeneuve d'Ascq 59650
France

_______________________________________________
Moose-dev mailing list
Moose-dev@list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev