Stop beta #835
Comments
|
@RichardC64, maybe this comment helps you to figure out the long-term picture: #674 (comment) |
CaerusKaru
added
the
discussion
|
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? |
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 #674 (comment) 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. #674 (comment) has the full explanation that is still relevant today. |
|
Although I've read #674 (comment) I 'm starting to believe that this project will never be released. |
|
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. |
|
@CaerusKaru is there any ETA on that decision? |
|
@kuncevic Not at this time |
|
@CaerusKaru no probs! |
|
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. |
|
Any news you can share on this matter? |
|
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:
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. |
|
It's weird because it's a library that works so damn well... |
|
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 "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. |
@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
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. |
|
Hi, It's been over a year since the last response on this thread. Thank you |
|
As a feedback, I switched to using Tailwind CSS and it's an absolute bliss. Flex Layout is nice on its own, but with Tailwind you gain the same simplicity, and added value with all the other styling that come out of the box (and the great component library). |
|
Note that you don't need a beta flag to justify breaking changes. A major version can also contain breaking changes. It's beta for over 5 years. But it's established and currently has over 300,000 weekly downloads. It's maybe time for the first stable relase. Don't worry: Every software has bugs. I think a beta flag will discourage some users/companies from using it. That may affects popularity. It's like never ending early-access/beta or 0.0.12345 version packages on npm. A matter of trust. "Just do it!" -- Shia LaBeouf |
As I understood this, the problem is not fear of bugs or breaking changes... but rather the internal definitions of beta/stable within google that prevents a stable release... One could also argue that you should not be afraid of a label or a definition (beta in this case)... Also a matter of trusting your self. "What's the matter, CIA got you pushing too many pencils?" -- Arnold Schwarzenegger |
Official statements from Angular DevRelhttps://twitter.com/mgechev/status/1450945968359153672
https://twitter.com/mgechev/status/1458823770622230529
|
|
Thank you @Splaktar for adding those links. Let me add some clarification to them so people don't necessarily get led astray. While I respect @mgechev tremendously, and understand fully where he's coming from, I think it's important to make a few things clear.
As for a summary recommendation: please understand your use case carefully. If your absolute, number one, immutable priority is performance and ditching dependencies: you can, and always have been able to, use raw CSS. If you want simplicity and powerful media query tooling, use this library. It may remain in beta indefinitely, but that doesn't mean it's useless. |
|
Yup... "Stop Beta" is what just happened unfortunately. This library is now "LTS"/Deprecated :-((( |
|
Leaves a lot of projects in a pretty crazy position with no real replacement. Bootstrap I suppose - although I hate that grid thing it tries to force upon you. And as the article says, there's always tailwind. |
|
Adding here as this was originally added to a different thread Hi The thing is, I can't do this by myself so I will need help from the community, so I would like to know what the community would like to see initially for things like: SLA for cutting releases* Thanks see original thread here |
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.
The text was updated successfully, but these errors were encountered: