Hapi and breaking changes

[kidtronnix]

Not sure what others think about the rate of breaking changes of this project, but for me it is starting to become a problem. @hueniverse I know you're fun-employed at the moment, ;), but 2 breaking changes in a month is causing me a lot of work to update stuff.

So I wanted to create an issue to act as a space for anybody with an opinion to offer on this matter, please get involved and maybe describe your use case.

For me, my use case is Hapi for serious personal projects, handful of hobby apps, and am trying to push to get Hapi used in production at my workplace. Ideally I like to be part of a project that is not afraid of breaking changes to cycle through bad ideas, but that respects that breaking changes should be minimised. In practical terms means about ~2 breaking changes a year.

I've always appreciated the detailed release notes with each major version and find this mitigates a lot of the problems of breaking changes but this only goes so far if we have too many breaking changes IMO.

So all devs working on hapi core team: Roughly how many breaking changes do you think is reasonable to expect?

All other devs / consumers of this project: How many breaking changes could you deal with? Has the rate of breaking changes been an issue for you?

[Marsup]

I don't see 2 breaking changes in a month, where ? Did you read #2765 ? What you're describing is typical case LTS aims to answer.

[edimoldovan]

I am not working on hapi and had no issue with the road to hapi v10. It is currently in production, using jwt, swagger, and other hapi plugins. Nothing broke in hapi for me, some plugins had issues with version numbers, but since I found them quickly I used temporary forks in packages.json and quickly submitted PRs to the corresponding repos, so that others can have an easier upgrade path.

From my perspective, we’re cool and hapi.

[hueniverse]

First, 10.0 is exactly the same as 9.0 except it moved to node v4. This is clearly stated in the release notes. If you are going to stay on node 0.10 you are going to be stuck with hapi 9.x forever, so you should not expect any more breaking changes, ever.

Second, 9.0 was the first breaking release in about 9 months.

Third, I will continue to release breaking changes as fast or slow as the project requires. The goal is to keep upgrade cost to a minimum which means multiple small upgrades are almost always easier and safer than one huge upgrade. I try to limit to no more than 1-2 big updates a year.

Fourth, counting the number of major releases without looking at the actual migration notes and complexity of the upgrade is counter productive. It's not about number of releases but about the effort required to keep up with them.

[kidtronnix]

Hey guys, sorry node isn't my 9-5 (YET!) so hadn't caught up with the v4 news in node and that you guys were recommending it for production. Now everything makes a lot more sense, should have dived round some more issues first.

@hueniverse Thanks for the clarification regarding breaking changes releases and how you aim for around 1-2 major changes a year. I also really agree with trying to minimise the work required to keep up to date by breaking down breaking changes into manageable chunks, rather than committing to an arbitrary number.

@edimoldovan Great to hear things went so smoothly. I will start upgrading my apps.

@Marsup Thanks for directing me to that ticket, everything became a lot clearer. Hapi-lts gets a huge +1 for me.

Thanks for all the info guys, as ever I am hugely impressed by the folks that surround this project.

[lock]

This thread has been automatically locked due to inactivity. Please open a new issue for related bugs or questions following the new issue template instructions.