At the moment, I can set a dependency on another app using either its published or development versions (which correspond to the published and master branches respectively).
Could we have the ability to set that dependency on any branch or tag that exists within the app’s git repository?
Use Case
I have a number of apps which provide common functionality and are set as dependencies for other, user facing apps. (My navigation module is one example: Dynamic Navigation Bar).
As those become used by increasing numbers of apps, I’d like to release new versions and use semantic versioning and tags to keep control of which app is dependent on which release.
4 Likes
This would be a great addition. I hesitate to make major changes to apps I use as dependencies because of the need to update all the other apps at the same time. It’d be great if they could continue to use the old version while I upgrade them at a slower pace.
1 Like
I agree, that would be useful indeed.
You would have to create the tags and alternate branches (other than “master” and “published”) outside of Anvil, right?
Yes, but that’s what I tend to do already anyway.
I’ll have to read up on Git’s branches and tags… specifically the scope and lifetime of names of branches and tags.
I’d be happiest if it were something that could be done inside of Anvil. Naming a published version and being able to have multiple published versions accessed by name, for example.
Since we are talking about expanding the integration with git from development / published versions to include tags and branches, I would like to add my 2 cents.
I had problems with the current implementation too, but, instead of (or in addition to) asking for a more flexible environment, I would like a more rigid one (maybe optionally activated).
The current behavior allows you to have production apps that depend on development branches of other apps. It also allows you to have AppA depending on AppB1 and AppB2, where AppB1 depends on AppC development and AppB2 depends on AppC published. When this happens AppA doesn’t even start, so you usually catch it quickly, but twice I had a panic day because apps that I had not modified in months stopped working. The reason was that, while working on AppZ, I had modified one of its dependencies dependency and created a conflict on 10 other apps.
My request would be that:
- Anvil should prevent me from publishing an app if there is any development version in its dependency graph
- When I publish an app all its dependencies should be automatically changed to published, and as soon as I modify it, all its dependencies should be automatically changed to development
The second point sound too drastic, but it is the policy that I (try to) follow. And since I started following it, I never had a problem.
2 Likes
This could still play nicely with tags. That is, a Published app could depend on a tagged dependency, as long as the tag was on the dependency’s Published branch.
By way of full disclosure, I do have a workaround for this at the moment.
For each major version, I create an app (e.g. “Navigation v1” and “Navigation v2”). I have a single, local repository and each of those apps is a remote within that repo with local tracking branches setup for ‘published’ and ‘master’ on the remotes. I can then use whatever branches and tags I want locally and push to release new versions.
The idea is that only breaking changes cause me to create a new app - minor and patch level changes just get pushed to the relevant destination.
However - as I use Anvil for multiple organisations (I currently have four separate anvil accounts) and I have several of these ‘common’ apps, it’s becoming somewhat cumbersome to manage!
1 Like