Groupie: Move breaking changes to a separate release cycle

[amitav13]

Hi guys,
It's great to see more releases coming out since @lisawray stepped back from the project. But the last 2 releases - 2.6.0 and 2.7.0 are breaking changes with no migration path to them. I personally can't upgrade beyond 2.5.1 now for any work projects - the extent of changes is non-trivial.

Describe the solution you'd like
If we are to follow semantic versioning, such changes should ideally be limited to 3.x releases. We could have 2 artifacts, or follow this migration path.

Or at the very least, deprecate but maintain existing functionality during updates so that we can gradually migrate.

[ValCanBuild]

Thanks for bringing this up. Yes, I wondered about how exactly to version the latest 2 builds. In the end I decided not to do a major version upgrade because the changes, while breaking, didn't seem on the surface that large. Perhaps that wasn't the correct approach.

I'm keen to encourage users to use the latest version. Which one of the breaking changes has caused the biggest pain point for you? I can create a new release with changes for an easier transition.

[amitav13]

I think from a general perspective, getGroup(position)'s functionality change is the most dangerous one since it wouldn't give a compile-time error, but silently change how it works. Would be hard to trace back to that particular change.

For the functions/classes that have been renamed, the ideal path could be to deprecate the existing functions and have their implementation just call the new function. Bonus if we could get a lint suggestion for what to replace it with. This way we can keep the releases at 2.x working as expected and when we're ready for 3.x, remove the deprecated functions.

[ValCanBuild]

@amitav13 I've opened PR #303 to hopefully address this. Please have a look and let me know if you're happy with the changes.

The next question is how to go about doing a release.

I can either:

• Republish 2.7.0 with these changes in, breaking it for all users who've updated so far or
• Publish 2.7.1 and mark 2.7.0 as a "do not use" while still having it available.

Leaning towards the latter.

[amitav13]

Thanks for the updates! I think we're good to go with the PR.

Leaning towards the latter.

I'd agree. Wouldn't want to break existing functionality for folks. But would it even need to be marked as a "do not use"? It's fine if they do continue using it right?

[ValCanBuild]

Thanks for the quick review!

But would it even need to be marked as a "do not use"? It's fine if they do continue using it right?

I suppose that's right. I'll just explain why 2.7.1 might be more appropriate

[ValCanBuild]

2.7.1 is now published. Thank you @amitav13

[amitav13]

Update - the change made in #287 is still an issue for us. While it's definitely in the right direction (the naming had annoyed me previously as well), the migration would take a while on our end. I'm not sure if this can be fixed with a @Deprecated either, since this is replacing a class entirely, rather than a function. The import statement, as well as code references, would have to be updated.

[ValCanBuild]

@amitav13 I realize that but unforutanely I don't really have any other suggestions myself. Bringing it back and having both classes live one won't be much use as you've pointed out. I think this might just have to be a global change every app would have to do.