Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Move breaking changes to a separate release cycle

See original GitHub issue

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.

Issue Analytics

State:
Created 4 years ago
Reactions:5
Comments:8

Top GitHub Comments

2reactions

ValCanBuildcommented, Oct 10, 2019

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.

1reaction

ValCanBuildcommented, Oct 22, 2019

2.7.1 is now published. Thank you @amitav13

Top Results From Across the Web

Release cycle / version numbers / breaking changes

If the next version is clearly not a major version, breaking changes must not be merged under any circumstances.

Policies and Practices in 18 Open Source Software Ecosystems

For example, they can refrain from performing changes, announce and clearly label breaking changes, or help their users to migrate from old to...

When and how to make breaking changes

Practices may include specific release strategies, deciding not to perform changes, mitigating the impact of changes through documenting ...

Implementation of Breaking changes in .com deployments

BEFORE the MR changing behavior is merged, include @gitlab-org/release/managers group as approvers for the MR, label the MR with "breaking change" label.

The Essential Guide to Release Management | Smartsheet

In this guide to software release management, learn how to plan, build, test, and deploy new releases, and find free templates.