Communicate Supported Lifetime and Provide Long Term Support (LTS) Versions

[desaroxx]

Is this a bug, enhancement, or feature request?

other

Briefly describe your proposal.

Problem Bug fixes and security patches are only available on the newest major version (with a very few exceptions).

To apply a necessary security patch / bug fix we often need to upgrade major versions. Upgrading major fundamental ngx versions has proven to be very time intensive and high in regression risk. Major version upgrades sometimes do take up to 1 month and leave an application vulnerable in the meantime until the security patch can be applied!

Furthermore based on conservative calculation our division spends at least 4 FTEs doing only fundamental ngx upgrades (not including management and QA efforts).

Solution Proposal 1: Communicate Supported Lifetime Each major release has a guaranteed maintenance window of X months and/or years.

The end-of-life is clearly visible to the consumers of the dependency.

https://en.wikipedia.org/wiki/Software_release_life_cycle#Support

Solution Proposal 2: Long Term Support Announce a few selection versions which will receive long term support. https://en.wikipedia.org/wiki/Long-term_support

This will limit how many major versions your team will need to maintain.

Good Examples

• NodeJS: https://nodejs.dev/en/about/releases/
• Java: https://www.oracle.com/java/technologies/java-se-support-roadmap.html
• Symfony: https://symfony.com/releases

Goal I (as a consumer) would like to reduce my major version upgrades to be limited to approximately once a year. So we would be ok with quite a bit shorter supported lifetimes than published by some the examples listed above.

Which versions of Angular and Fundamental Library for Angular are affected? (If this is a feature request, use current version.)

-

If this is a bug, please provide steps for reproducing it.

-

Please provide relevant source code if applicable.

-

Is there anything else we should know?

-

[Agrim-Jain-Dev]

We are also facing the same issues. We are spending a lot of time and effort to manage the library. The above two proposals looks good. This will be helpful for sure. Thanks!

[droshev]

@desaroxx Thank you for the issue. We take each feedback very seriously. Let us analyze the issue in more details and then I am sure we can find a working solution.

[dineshbabu3395]

Thank you very much for making this a high priority and I hope that the outcome is positive.

[desaroxx]

Scenario This is the setup many of our apps are running:

my-app@2.0.0 (needs: @fundamental-ngx/core@^1.0.0)
|   \  
|    sugar-fields@10.0.0 (needs: @fundamental-ngx/core@^1.0.0)
|   /
@fundamental-ngx/core@1.0.0

my-app: developed by a customer facing team sugar-fields: developed by Roadrunner fundamental-ngx/core: developed by fundamental-ngx team

Lets assume we find a bug "button has wrong color" in the fundamental-ngx library.

Problem In the meantime @fundamental-ngx/core@3.0.0 was published.

the fix for "button has wrong color" requires following steps:

1. sugar-fields needs to upgrade to @fundamental-ngx/core@3.0.0
2. sugar-fields published new major version sugar-fields@11.0.0
3. my-app needs to upgrade @fundamental-ngx/core and sugar-fields@11.0.0

Estimated duration: 1 month

Here we lose a lot of time with:

• communication overhead
• fundamental-team or sugar-team has other priorities ATM
• fix breaking changes caused by angular/typescript/fundamental

Ideal Scenario Fix for "button has wrong color" is published for LTS version as @fundamental-ngx/core@1.0.1.

1. my-app only needs to bump @fundamental-ngx/core from 1.0.0 => 1.0.1

Estimated duration: 2days

Benefits

Benefit 1: sugar-fields team isn't involved at all (doesn't need to do anything) Benefit 2: my-app team only needs to bump patch version (don't need to worry about breaking changes introduced by angular/typescript/fundamental)

[desaroxx]

see #9816

it intends to include LTS