24 Feb
2019
24 Feb
'19
8:40 p.m.
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-withou…
On Thu, Feb 21, 2019 at 8:34 AM Stéphane Ducasse <stephane.ducasse(a)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(a)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(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
--------------------------------------------
Stéphane Ducasse
http://stephane.ducasse.free.fr
http://www.synectique.eu / http://www.pharo.org
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(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev