@mksd fair points. Would having a dedicated environment for the 3.0.x branch make it work for you?
I feel it would be okay for this release to do it on master and prepare the branch approach for future releases.
I recall @ibacher was reluctant to freeze versions on master, because it would stop devs from developing against the latest snapshots, but if in fact not much development is happening that’s something we could live with. I’ll let others to chime in before making the final call.
@raff a first 3.0.0-alpha tag (on which all ESM versions would be fixed) would just be transient anyway, we can make it follow immediately by a subsequent commit that resets all ESMs to next. All this on the main branch.
And so on and so forth for 3.0.0-alpha-1, 3.0.0-beta, 3.0.0-rc, etc.
Actually, all those ESMs are probably not in movement right now, I wonder if @dennis, @hadijah315, @ibacher and @vasharma05 could help fix those that can already be fixed?
So you won’t need it to run on dev3 for testing for days? If that’s the case then it shouldn’t be an issue at all and I would go ahead and do it on the main branch given it will be just for the time of running a build and having it tagged.
Correct.
However whatever is released should be deployed on o3.openmrs.org. In my understanding the demo environment (o3 then) should serve the latest full release available.
I do think we need a separate branch for the release, though I don’t love maintaining two branches, the requirements around dev3 are very different from the requirements around releases.
The release branch should be deployed to test3 and from there, promoted to o3. A branch here makes some sense: dev3 is an integration environment that exists largely to ensure that all the RefApp MFs play together well and to allow developers to work on one module at a time while still having it display as part of an integrated application. The requirements for doing a release are somewhat different.
This doesn’t have a simple answer, but assuming what you want to do is use a core set of modules and add some additional ones, our tooling doesn’t support that (basically, the assemble command takes a single configuration file). However, you’re free to do whatever you want before running the assemble command to create a spa-build-config.json file with whatever contents you need.
The requirements around dev3 are very different from the requirements around releases.
Could you give an example of this. Does it affect the distro/frontend or just docker side of things.
This is entirely about the frontend side of things. In 3.x, our frontend is built as a series of microfrontend. Each microfrontend is self-contained, but not a complete application. In order to be able to work on one MF at a time but still have the presentation of the full application, you need the rest of the frontend components available somewhere. Our developer tools for frontend applications default to using dev3 to provide that surrounding context—without dev3 in the role it currently has, each frontend developer would be required to run the full application locally… and it would be harder to ensure that everyone was working with the latest versions of the components they don’t care about.
Basically, dev3 is critical to our frontend developer workflow and the sole reason that system exists is to support the frontend developer workflow. dev3 does a good job of supporting this role, but the structure of it obviously doesn’t work well for releases; instead of trying to square competing requirements (we need an integration environment running the latest version of everything vs we need an environment running known-good versions of everything) in one system, I’m just suggesting we utilize test3 and o3 for actual releases and distributions. This actually mirrors the setup we have for 2.x…
Are we ok to say that for now we just create release commits (and tags) on main? And every time we make one, we push a subsequent commit that sets back (some/all) ESMs versions to next?
Then we will decide which tags should be deployed where, between the test3 and o3 environments.
I’m fine with doing that on main, but I’d still rather have two branches so that updates to other modules–things that probably aren’t ready to be part of the RefApp yet, like dispensing and maybe the form builder–can continue to be worked on. (Currently, the way those applications get updated in the dev3 environment is to build a new version of the frontend images). If we move main to being the release branch, that’s fine, but then the current stuff that builds dev3 should be targeted at a different branch. This is also part of why I want to refactor out the metadata into a separate, versioned artifact.
Is it possible to get an alpha release ready this week with the current state? We can then continue with the development and possibly do the required refactoring.