Bump version to 1.0.0

[tjschuck]

@pfiller @kenearley For the next release, you should just bite the bullet and 1.0.0 this sucker, particularly now that full documentation is here!

From then on, we should do our best to follow the SemVer spec.

❤️ ❤️ ❤️

[koenpunt]

All that love! ❤️

[pfiller]

I just tagged a version and I went with 0.14.0.

Going to 1.0 is long overdue so let's make that a goal. There's really only 1 blocker in my mind, but I'd welcome you guys to weigh in on any other changes we should make before we finally pull the trigger. @stof @kenearley @koenpunt is there anything in your mind that keeps us from making this a reality?

My list:

• Replace all instances of chzn and liszt with chosen.

[kenearley]

Off the top of my head, I can't think of anything. Are there any options that we would want to rip out. Now would be the time.

[stof]

what about making search_contains the default search behavior ? According to issues opened regularly, it seems to be the expected behavior for lots of people (especially as the detection of beginning of words also has issues with non letters chars and with non-latin encodings)

and as there is a work to make Chosen framework-independent, I think it would be great to wait until we have it for 1.0

[tjschuck]

@stof I'd like to avoid the "arbitrary" versioning of thinking, like "framework independent = big deal! = new version" and instead rely on the well-specified system of SemVer. So before we hit 1.0, all we would need to do is get the API to a reasonably non-changing place (like @pfiller's chzn/liszt -> chosen goal). Since this is already being used in production by major players (Harvest included!), it's somewhat silly to call it pre-1.0. We should hammer down the API, document it (done!), and 1.0 it. If we make future changes, then just bump the version then, according to what SemVer says is reasonable.

[pfiller]

I agree with @tjschuck on this. Just because we waited 2 years for 1.0 doesn't mean we can't go to 2.0 in a month if we need to.

[koenpunt]

I guess the following is missing on @pfiller's list (according to his comment here):

• Remove max_selected_items option

[koenpunt]

For tracking the process to 1.0 I've created the milestone 'Chosen 1.0' and attached it to @pfiller's issue #1412.

[Daniel15]

Honestly I personally think some of the accessibility issues should be fixed before a 1.0 release (see #264)

[tjschuck]

@Daniel15 The accessibility issue is an important one, but it is not a blocker for 1.0. Like @pfiller said, going to 1.0 does not stop continued versioning. Accessibility enhancements are backwards compatible, and can even be a patch-level version bump. So going to 1.0.0 now with Chosen does not stop 1.0.1 from having accessibility upgrades.

1.0.0 is not the end of the road -- it's just pulling out of the driveway :)

[pfiller]

Remove max_selected_items option

I went back and looked at the pull that brought this feature in (#530) and I think I'm ok with leaving it in. It's true that I don't really like it, but I don't think it's terribly difficult to maintain and it was a fairly common feature request. As @Polycode pointed out in that discussion, our limit is similar to the browser's native maxlength on text fields.

Though I do think it's confusing to simply stop a choice from being selected, Chosen does provide a way for developers to notify users when the max has been reached. Just because someone can do something bad with an option (not notify users) doesn't mean we should kill the option entirely.

That's my $.02. Does anyone feel strongly about max?

[kenearley]

Does anyone feel strongly about max?

I do not. Since it's easy to maintain and we offer a developer a way to notify the user, then it seems fine to me.

[pfiller]

Alright, I'm going to close this issue. Will make the 1.0 switch today (just over 2 years after we announced Chosen)