flex-layout
flex-layout copied to clipboard
angular
Stop beta
Proposal
Stop beta
What is the summary of the proposal?
This "excellent" package is still in beta. I know that the product can still be improved but a lot of company refused to use beta product. So i think it would be nice to publish a real release, event if there is still some "small bugs"
What is the proposal?
Publish a "first" release.
@RichardC64, maybe this comment helps you to figure out the long-term picture: https://github.com/angular/flex-layout/issues/674#issuecomment-374866400
Also seems like a duplicate of https://github.com/angular/flex-layout/issues/752.
From reading #674, it looks like Angular v8 may be the proper time frame for a possible GA of @angular/flex-layout. That could be sometime around April 2019 if I'm not mistaken.
With reference to #871 I also find it unusual for a minor version upgrade to require a major upgrade of a subsystem - in this case Typescript. It means we remain - for a while - on a version of Flex which has some bug fixes, but isn't "version 7", but isn't the latest version of "version 6". Can the team also adopt the policy that subsystems are not upgraded except when a major version implemented? In other words, minor increments should only be for bug fixes.
With reference to #871 I also find it unusual for a minor version upgrade to require a major upgrade of a subsystem - in this case Typescript. It means we remain - for a while - on a version of Flex which has some bug fixes, but isn't "version 7", but isn't the latest version of "version 6". Can the team also adopt the policy that subsystems are not upgraded except when a major version implemented? In other words, minor increments should only be for bug fixes.
It's to keep in line with Angular's major versioning. That way you know that Flex layout 7 works with Angular 7, 6 works with 6, etc. I think there's a lot more value by not having to guess at major versions than to stick with purely semantic versioning. I totally see your point though.
Response https://github.com/angular/flex-layout/issues/674#issuecomment-374866400 is one year old!
@richardC64, Ivy hasn't landed yet so IMHO that answer remains valid and up to date. I'm not sure Ivy will be the default renderer before @angular 9.0.0+. Be prepared for some more beta period until... 2020?
This library has been in 'beta' far far longer than anything else I've ever seen. Doesn't it lose meaning at this point? Why not just make it official?
@jpike88 because more breaking and likely significant changes are coming before the team is ready to call this project GA.
Users of this project need to understand that. The beta tag accomplishes this.
https://github.com/angular/flex-layout/issues/674#issuecomment-374866400 has the full explanation that is still relevant today.
Although I've read https://github.com/angular/flex-layout/issues/674#issuecomment-374866400 I 'm starting to believe that this project will never be released. Also, how is possible to figure out which versions of the other @angular libs this project is compatible with?
This library is major-version aligned with the versions of Angular (v8->v8). We keep it current with all future releases once Angular CDK issues a compatible release (since we depend on them).
As for stable release, if you don’t believe we’ll ever make it there that’s fine. Plenty of people have chosen not to stick around and wait. You have to make the right choices for your project. However, stable release or not, we believe this library provides tremendous value. Not only that, just because you don’t believe we’ll make it doesn’t mean we never will 😄 .
Personally, I’m waiting until the v9 release to restart efforts towards the redesign. Doing so earlier means likely getting crushed by the freight train that is Ivy.
Now angular v9 is also released with default Ivy. When are you planning to do stable release? I saw the library v9 version updated 7 days ago still in beta.
Angular 9 has been out for 3 months now... this library has to be record breaking in how long it has been 'beta' in name only. @CaerusKaru this 'redesign', are there any blueprints, scopes, roadmaps etc etc that can indicate to what degree breakage will occur? Can people expect this library to go stable this year or is it going to continue as is?
Somehow I doubt that in the history of software, this library sets the record for longest beta, but point taken. The redesign is in #1185, and comments of all types are welcome. It is an enormous departure from the current library, and even with Angular schematics, I doubt it's an easy feat to introduce. Add to that the fact that the framework team has not seen or discussed this new proposal yet.
I can't offer a tangible update at this time, except to say that I share your frustrations. I'm not going to stop pressuring the team to pick this up, but it's difficult given their shifting priorities.
@CaerusKaru Why don't you just remove the word "beta" from the release schedule. Beta in my mind is to proffer a piece of software to gain further customer feedback before going live. I know for certain that flex-layout is inside multi-million pound software applications, hardly beta. I don't think anyone would really know or indeed care what is around the corner, even if it is a complete redesign.
@inthegarage You've been following this thread long enough to be aware of our rationale for keeping the beta moniker. That rationale has not changed. We have a whole list of applications that use this library in production at the ultra high-exposure level. Beta in our case has nothing to do with stability, but unfortunately there is no tag we can provide that conveys what we actually are, so beta it is.
I also think it's dangerous to say that no one would care about the redesign; the aforementioned high-profile apps come to mind in terms of maintaining relative stability. Like I said, it's still our desire to lobby the Angular team to support our official release, but that is still yet to happen.
Wouldn't a redesign as drastic as shown in that PR be better off as a separate repo?
@jpike88 Yes. Full transparency here, the Angular team has basically two schools of thought right now regarding this library. Either a) they support it fully, meaning that it must follow the strict standards of Angular first-party libraries, or b) they do not support it fully, and this goes into community-management (e.g. as ngx-layout).
In the case of a), it's most likely at this point that they would take the RFC design as the new implementation of Angular Layout (#713), and then deprecate this library fully. Those willing to migrate can and should at that point.
In the case of b), it's also likely that we would launch the RFC, though there's a possibility we would continue to support the legacy version for a predetermined period of time.
In either case, Angular Flex Layout will likely never exit beta in its current format, unless something drastic happens. The Angular team just does not believe in its current implementation enough to issue such an endorsement. The RFC in my opinion is our best bet towards legitimacy, but that is also not fully determined. At the very least, it gives us more options.
This issue remains open to lobby the team and show that the community desperately wants a library that is not just some weird side project. I also want to acknowledge that in no scenario does this library get thrown away completely; we are committed to supporting it 100% for the foreseeable future, whether it's the current state, or the RFC if/when it lands.
The Angular team is currently editing/reviewing a new roadmap and evaluating the scope of the team's responsibilities. There should be some news about this over the northern hemisphere's summer. That doesn't necessarily mean that a decision on this library will be made at that time, but hopefully that helps you understand part of the process that is underway.
None as of yet. I promise you, the second I know, work will begin one way or the other depending on which direction we choose to go. I understand the anxiety around not knowing, but unfortunately there isn't more I can share on this right now.
Staying in "beta" version has further implications: it is considered by many "not yet fit for public consumption" link to node-semver pre-release tags. In many companies, the policy is not to use pre-releases versions in productive environments. This automatically disqualifies this library.
I would encourage you to release a final version because:
- Keeping beta has undesirable implications, and the result is basically we cannot use it.
- Four years in beta is not understandable.
- Expecting having something perfect and finished is unrealistic.
- Major refactor and future breaking changes is completely acceptable each time you increase the major versions.
I understand you are at a crossroads and you want to prevent breaking the web choosing the wrong path, but from my point of view there is no excuse for not releasing it now and then (if necessary) breaking it in the future, following semver.
I understand your frustration, no one more than I would love to see as many people use (and benefit from using) Angular Layout. Unfortunately, the factors you've laid out are not enough to sway the project planning for the Angular team.
- The Angular team is not interested at this time in garnering interest towards or driving up use of this library
- The length of time in beta is immaterial to the Angular team, since they don't have an interest in fully supporting it anyway
- While no solution is perfect, there are solutions that are deemed "acceptable" and not, by the standards endorsed by the Angular team
- We're not talking about just minor breaking changes here. The breaking changes could change the entire structure and usage of the library itself. See #1185 for more detail.
The "excuse" here is that the Angular team is finite, and its resources finite. My, and our consumers', will is not enough to override this simple fact. I'm sure if 100% of respondents ranked Angular Layout as their number one priority in the annual Angular survey, that might change. Until then, this project remains in beta unless announced otherwise.
it is considered by many "not yet fit for public consumption"
@CrlsMrls that is intended.
And +1 to everything that @CaerusKaru said above.
Ok thanks for the clarification. It helps.
Then, what would you advise as a stable replacement for this library?
I've been using it with great success, but I'm open to consider switching to the supported way if it's not suitable for production on the long run.
@CaerusKaru thank you for spending the time with your clarifications. Very appreciated.
@qortex https://material.angularjs.org/latest/migration#changes-to-layout-features does a pretty good job of breaking this down and was reviewed/approved/published by the Angular team.
I've done this for a few apps now and it basically boils down to
- Directly apply the same CSS (Flexbox, Grid, Media Queries, etc) that Angular Flex Layout currently applies in your app
- Use CDK Layout for observing breakpoint changes in TS
This may also end up being one of the safest ways to move towards the new "Angular Layout" redesign as you would then be free to start using those new APIs when they are stable w/o worrying about having two layout libraries in the app or having conflicting directives.