Changes on master have not yet been released

[runspired]

Latest released version is 2.0.1. Changes on master would fix many deprecations.

[gilest]

Agree – @lukemelia would it be possible to cut a release? 🙇🏻

[runspired]

I tested latest master in our app and it was broken, might be worth adding some tests and doing some debugging before releasing.

[gilest]

What was broken? Just migrated an app from the older package ember-radio-buttons (plural) to latest master and didn't have any issues.

[runspired]

@gilest groups of buttons no longer worked at all, they acted independently and their actions wouldn't fire.

[m0glan]

Any update of an ETA for the 3.X release? Thank you.

[lukemelia]

I'm happy to cut a release but need help confirming or fixing master's functionality.

[m0glan]

@lukemelia What exactly seems to be the problem? I cloned the project and ran the tests and they all pass. Console is clean, no deprecation warnings or anything.

[m0glan]

@lukemelia Just tested latest master on our project... nothing seems wrong. Works as expected. Am I missing something?

[gilest]

@gilest groups of buttons no longer worked at all, they acted independently and their actions wouldn't fire.

I didn't manage to verify this although I may not have tested all usages. Working in production for a client pinned at b2ab65f (latest master commit).

[lukemelia]

OK, I'll go ahead with a 3.0.0-beta.0 and we'll see how it goes. Thanks all.

[m0glan]

Thanks a lot, much appreciated!!

[lukemelia]

Released as https://github.com/yapplabs/ember-radio-button/releases/tag/v3.0.0-beta.0

[lukemelia]

Please give it a whirl and let me know if it is working for you.

[m0glan]

@lukemelia Just added this last update to our project. So far so good, tested a few of the places we're using radio buttons in, nothing out of the ordinary so far, no errors, no warnings. Passed it on to our QA to have a deeper look.

Also we have pretty good test coverage for our project and all of the tests pass.

[lukemelia]

Thanks for the update @vmoglan. Keep us posted here.

[runspired]

I'm no longer working on the project I had issues with so can't retest, though I'm starting to have a theory that it might have been due to either usage of string actions or a yarn bug that can happen when installing from a GitHub url.

[lukemelia]

@runspired 👍 Thanks for following up.

[m0glan]

@lukemelia perhaps my last update, our QA ran automated + manual tests and everything worked as expected. I think this may be good to go.

[Benjy1979]

Hi,

how do I install version 3, as mentioned in the readme. When I read the guides it only really covers how to install npm or yarn packages. e.g ember install ember-cli-sass

What would I do with a zip file?

[m0glan]

@Benjy1979 I think ember install ember-radio-button@3.0.0-beta.0 should do

[jkallman]

I've been using 3.0.0-beta.0 in my app (Ember 4.6) and haven't run into any issues yet. Are there any remaining steps before the official release of 3.0.0?

[tehhowch]

I think the issue is when a closure changed action isn't provided, the expected native behavior doesn't work for apps that are still working through a mix of old and new syntax.

In v2, there was a computed-aware update to groupValue -- the commented code is still present (but obviously won't work if uncommented):

ember-radio-button/addon/components/radio-button-input.js

Lines 16 to 20 in 732619a

	@action change() {
	if (this.args.groupValue !== this.args.value) {
	// this.set('groupValue', value);
	once(this.args, 'changed', this.args.value);
	}

I ran into this when a set of has-block RadioButton components provided neither the @name argument nor changed, and relied instead on responding to the update of groupValue. Instead, clicking any of them persisted the current selection, and added the just-clicked input to the selection.
When I supplied the "name" argument, I got the expected "radio button" interaction (only one could be selected), but still didn't have the expected reactivity (since the component was using computed properties based on the value passed in as groupValue).
When I provided the change callback, I was able to drive the reactivity as expected, through this.set in the calling component. I am not currently able to test whether the change action is still optional, as that component is very firmly backed into computed properties at the moment.