Transition from Versionless to Versioning

[TsayAdobe]

Versioned Milo can bring about several significant benefits and help address challenges that the development teams have faced with versionless Milo.

Firstly, versioning provides a structured approach to software management, making it easier to communicate changes to app teams. With version numbers, app teams can clearly see the evolution of Milo and understand what updates they are receiving.

Additionally, versioning can help mitigate risks, particularly in situations where Milo changes have led to system outages. With versioning, an app team gains the ability to roll back to a previous version if a critical issue arises, ensuring system stability and reliability.

Here are some specific advantages of transitioning to versioning for Milo:

1. Unrestricted Development: Milo development won't be hindered by restricted periods. Teams can work continuously on improvements and new features, enhancing agility.

2. Controlled Breaking Changes: Milo can freely introduce breaking changes in a new version, allowing for innovation without compromising existing functionalities in consuming apps

3. Minimized Backward Compatibility Code: With versioning, Milo can minimize the code required for backward compatibility, streamlining development efforts and reducing technical debt.

4. Empowered App Teams: App teams gain the autonomy to decide when to upgrade Milo, aligning updates with their own schedules and priorities.

5. Enhanced Quality Assurance: App teams can take ownership of QA for specific Milo versions, ensuring that updates meet their specific requirements and standards.

6. Rollback Capability: The ability to rollback to a previous Milo version provides an essential safety net in case any blockers or critical issues are encountered after an update.

7. Maintenance Mode Support: For consuming apps in maintenance mode, they can remain at an older Milo version without being forced to adopt the latest changes, offering stability and predictability.

By transitioning to versioning, not only can we address the challenges that versionless Milo has posed, but we can also unlock greater flexibility, control, and stability in the development process. This shift allows teams to work more effectively and align software updates with customer needs and business goals.

The implementation of versioning can be as straightforward as introducing a version path in the URL, for example:

https://main–milo–adobecom.hlx.live/libs/v1

[mokimo]

Do you have a concrete use-case/recent pain-point for this or is this food for thought? Milo is supposed to be evergreen comparable to how feds was in the aem/dexter world and the milo core team had given this a lot of thought during conception, as far as I am aware.

Consumers don't need to worry about upgrading or being on an outdated version (ever looked at package.json versions for projects? Libraries tend to be implemented once and rarely upgraded from there on)

Controlled Breaking Changes: Milo can freely introduce breaking changes in a new version, allowing for innovation without compromising existing functionalities in consuming apps

This is already possible, but depending on the feature needs a bit of planning. Speaking for our team, we released a completely new global navigation in a non-breaking way and completely independent of the previous milo navigation.

Also, Rollbacks are automatically included in our workflows, if we break anything - we can and did in the past, undo a PR that has led to issues.

[3ch023]

Also, Rollbacks are automatically included in our workflows, if we break anything - we can and did in the past, undo a PR that has led to issues.

And, what I find important, we only revert 1 PR causing the issue. As opposed to reverting the whole release, which might contain another PR fixing another critical issue.

[mokimo]

Since a lot of your points resolve around the stability part - it IMO makes sense to investigate how we can provide more stability and feedback to developers merging a PR and ensuring the site is still running as expected for various consumers rather than trying to create a versioning system for milo

Empowered App Teams: App teams gain the autonomy to decide when to upgrade Milo, aligning updates with their own schedules and priorities.

Enhanced Quality Assurance: App teams can take ownership of QA for specific Milo versions, ensuring that updates meet their specific requirements and standards.

Rollback Capability: The ability to rollback to a previous Milo version provides an essential safety net in case any blockers or critical issues are encountered after an update.

Maintenance Mode Support: For consuming apps in maintenance mode, they can remain at an older Milo version without being forced to adopt the latest changes, offering stability and predictability.

[3ch023]

Agree with @mokimo that we should rather invest more into making PR merges safe.

We could enforce running nala tests on each PR before the merge is possible. It should be the responsibility of a consumer to provide a set of critical tests that will run on each Milo change PR and make sure nothing is broken on your page, be it the homepage, CC/DC page, or a specific feature your team is working on.