Ensuring the main branch of the Studio always works (in both ways of using it)
As for other projects, the main branch of the Studio must always work without bugs.
As we know, the underlying projects (CL
The Studio only depends, syntactically, on PathWays. Thus, whenever a new PathWays snapshot is deployed, with the same version number as the one that the Studio depends on (https://gitlab.inria.fr/cedar/connection-studio/-/blob/main/webservices/pom.xml#L28), the Studio is affected, and potentially broken.
To avoid this, here are two possible solutions:
-
Whenever PathWays evolves in ways that may affect the Studio, the PathWays version is bumped up, e.g., 1.1 or 1.0.1, etc., and PathWays is deployed. Then this new version is deployed as a SNAPSHOT. The Studio will keep the dependency on the previous version, thus be stable. Upon deploying a new version of PathWays, @nbarret could file an issue in the Studio of the form "adapt to PathWays 1.1", then someone could handle that issue in a branch, and only when it's finished and good, we could bump up the PathWays version in the Studio's
pom.xml
. -
Whenever PathWays evolves in ways that may affect the Studio, PathWays is not deployed. Instead, an issue is filed in the Studio, to inform of the new PathWays version (
⭐ ) . Then in a branch, the Studio could be adapted to the new PathWays, and only when this works, we (deploy the new Abstra and immediately merge the Studio branch adapted to it).
I think 2. is not so good, because it's not sufficiently easy to get the new PathWays in (mvn
) mechanism. For this reason, I think method 1. above is preferrable. It also seems more logical: if we change PathWays (possibly because something changed underneath, etc.) in ways that make its functionalities evolve, it makes sense to bump up the version.
@nbarret @x-SEbel @x-TGaliz @mmohanty please tell us what you think!