The Published App
Odds are, you have Published your Anvil App (or you plan to Publish it). This is great for ongoing development. You can continue to evolve your App, knowing that existing users are not affected by your subsequent changes to Forms, Modules, and Server Modules, until you say so. (As I understand it, Tables and table contents are not version-controlled, so change these with caution – or under a new App name entirely.)
Only one version of an App can be Published at any one time.
The Published Library
You may also be considering factoring your App into a series of Libraries, for reuse in a variety of Apps. This is also great for development, for an even longer list of great reasons.
Because a Library is just a specially-marked App, it, too, can be Published. This means you can evolve your Library in the same way as your App. When the Library reaches a release point, you Publish that version. Any App using the Published version won’t see the Development changes.
Only one version of a Library can be Published at any one time.
Synchronizing Lib and App
Congratulations! Version 2 of your Lib is completed ahead of schedule. None of the Version 1 functions exist any more, but that’s okay; only the almost-finished Version 2 of your App will use this Library. You go ahead and Publish Library (v2).
And all hell breaks loose with Version 1 of your App, which, at the moment, is the App’s currently Published version. You quickly re-publish v1 of your Library, and everything goes back to normal.
What happened? You Published App version 1 using Library version 1. Didn’t you?
Nope. App version 1 always uses whichever version of the Library is currently Published, not the version that was Published at the time. Dependencies are not pinned at the time of publishing, but are evaluated dynamically.
Please note that this is not a bug. This is by design. This allows a library author to Publish needed minor corrections or enhancements, and have them go into immediate effect. It’s up to the author to make sure that complete backwards compatibility is maintained before Publishing.
So, if you had made your Library v2 fully backwards-compatible, this would not be an issue.
Alternatives
Compatible or not, Lib v2 needed to be Published, but there were at least two ways to do it:
- Publish Lib v2 and App v2 at virtually the same instant. This can work, as long as there are no other Apps using Lib v1.
- Publish (and use) Lib v2 as a distinct App library, under a distinct library name. (Perhaps you are using Semantic Version numbering. In that case, you might incorporate the Major version number in the name.)
If you can see other options, please reply and share!
Of the above, solution 2 is probably the most general, and the most forgiving. It lets you continue to run a mix of Apps, some using v1, some using v2, and lets you evolve each of them on its own schedule.
Note that this behavior is transitive: not only does it apply to the Published Library above, it applies to any other Published Library used indirectly. Whatever solution you choose to apply, make sure that you apply it consistently throughout your dependency tree.
