Replies: 8 comments
-
|
Thanks @Mohammer5 for the write-up! I agree with 90% of this and think we need more agility in our versioning. The problem, unfortunately, is that this isn't actually true:
The reason for this has to do with
If App 2 is the only place using
So we get a new version in App 2 and App 1 is totally fine, but we have duplication in App 2. This is problematic because we use React Context to determine z-indexes, so a Select rendered by the app in a modal in the App Shell (not an actual problem here, but you get the idea) would use two different Context instances and the z-indexes wouldn't be set correctly. If we then upgrade the version in @dhis2/app-shell to avoid the de-duplication, we get this:
So now we have duplication in App 1, let's upgrade that:
Almost there, but now there's duplication in
This is eventually-consistent and we get to the right place, but we had to upgrade every app (potentially 30+) and library in the network to make it work, and in the meantime there were lots of opportunities for transient bugs. Also, this requires a major version bump of all our libraries ( This isn't to say we shouldn't do major version bumps, but if we de-friction them we need a solid plan of action to ensure the "ripple" through our entire ecosystem (including apps developed externally) is fast and streamlined, otherwise we're asking for a world of pain. |
Beta Was this translation helpful? Give feedback.
-
|
I agree. I think for a small team such as ours, when releases get too big and slow it seems to clog up the entire pipeline and become way too big for us too handle comfortably.
I'm not sure if Chrome and FF versioning is also based on semver (what do they consider their API for example), but I get the analogy. I agree that:
For planning, I would propose that we use Github's milestone planning, to assign issues to milestones/versions and make it more explicit what's going to go in which future release. It would make things more explicit and plannable in my opinion (and then we could have meetings about it as well if necessary). I think that's also something that we have done wrong in the past. Release goals would move and shift from under us, and every breaking change would just be added to the current major release. Formalising this a bit would help I think. |
Beta Was this translation helpful? Give feedback.
-
Definitely onboard with these points as well as milestones! And better cross-repo roadmap planning is critical to address the waterfall effect above |
Beta Was this translation helpful? Give feedback.
-
|
Very valid points by all of you above. Definitely a big dilemma choosing between the cons of large major versions and cons of continuously having to upgrade all libraries to keep matching ui versions. Hadn't actually thought of upgrading the Personally, as a consumer of However, this might not be ideal from a development speed point of view (aka quantity) as we'll spend lots of time upgrading and releasing new versions of the affected apps. But I get the feeling that in the DHIS2 world we favour quality and robustness over quantity, which why I'm ultimately in favour of smaller major versions. Also like to point out that I'm very much in favour of scoping the releases to target specific components. This will increase quality, as e.g. I'm currently sitting on a lot of "half upgraded, sort of broken" components, which are waiting for missing features and bug fixes. These features/fixes could in themselves be causing a breaking change. And last thing we want is multiple breaking changes (with the version bump dance explained above) for a single component within the same app release (e.g. 2.35). So it's better to focus on a single component and get it 100% working and out the door, as the release of the affect app will be blocked until everything is indeed working as well as (and hopefully better) than the previous version of the app. |
Beta Was this translation helpful? Give feedback.
-
|
Agreed. Also, now that I've spent quite some time going through all our changes for the release post, I think that the latest release was just way too big for a team of our size. I think the sheer quantity of code we had to review was quite overwhelming, so a lot more ends up slipping past us that we probably would have noticed if it were a concentrated, small, release. |
Beta Was this translation helpful? Give feedback.
-
Agree with this 💯 Good suggestion. I also agree with the other things mentioned here. v5 was way too much (again). |
Beta Was this translation helpful? Give feedback.
-
This sounds eerily familiar to the i18n singleton problems we were having, and I think it is somewhat concerning to have to restrict to a single version (instance?) of a ui library. Is there any way this can be avoided? |
Beta Was this translation helpful? Give feedback.
-
This is a bit off-topic, but I can shine a little bit of light on that.... I had created a little POC of how this could technically be avoided. It was pretty ugly and very simple, but it did work. I can't find the PR (if I ever made one) but pretty sure it just involved changing this: const LayerContext = createContext({
node: document.body,
level: 0,
})To this: const createLayerContext = () => {
if (!window.dhis2UiLayerContext) {
window.dhis2UiLayerContext = createContext({
node: document.body,
level: 0,
})
}
return window.dhis2UiLayerContext
}
const LayerContext = createLayerContext()I discussed the possibility to implement something like this, but the preferred solution was to just let the app be responsible for using a single version of the lib instead. I think on balance that was the right decision, because the solution above has quite a few limitations and potential problems. But perhaps if someone could come up with a better solution that doesn't involve using the global object, we could implement that.... |
Beta Was this translation helpful? Give feedback.
-
We've had two major releases that were quite cumbersome: Version 4 & 5.
After releasing v4 we've realized that it took quite long and came with a few problems (parallel development; handling bug-fixes on
masterwhile adding features onnext; etc.)Yesterday @ismay, @HendrikThePendric and I talked about that for a brief moment and we all agreed that we've been a bit afraid of major version bumps in the past and wanted to consolidate as many breaking changes in one major version.
I think we shouldn't shy away from having more releases with breaking changes as long as they have a clear scope (if we release a breaking change of the Transfer component, only apps using that one would have to update their code and only the
Transfercomponents). We should still be careful to not have constant breaking changes though! But I'd prefer the way Chrome and Firefox release their major versions and not the way Firefox has done it in the pre-v10-Firefox-era.Of course creating a mono-repo is a huge effort and it makes perfect sense that it uses up quite some time, but if we had split this into several releases (just creating the mono repo with no changes; then do individual breaking changes), we would've released some stuff already and wouldn't have to think about it anymore. The
formsstuff for example will affect only a couple of apps, theTransferchanges even fewer while other changes might affect a lot of apps.So I'd like to discuss our release strategy a bit in regards to how often we should allow breaking changes and how we'd want to group them so we don't have another breaking change every week. I think what would make most sense to me is: If there's an issue that would cause a breaking change, we sit together / discuss it on github and try to figure out what the actual problem is, what a proper solution could look like, how much work it is and then consolidate all that work into one breaking change release.
Beta Was this translation helpful? Give feedback.
All reactions