[mwpmaybe]

Well, they've changed in the past... it's fine as long as the plans corresponding to the PlanIDs never get smaller or more expensive. This particular change violates that assumption and so is definitely not fine.

[Matheus28]

The hardcoded plan (PlanID 2) that I had in my program was pointing to a 4 GB 2 CPU plan (4 GB), now it's pointing to a 2 GB 1 CPU plan (2 GB).

[biot]

There is an API method to query plans: https://www.linode.com/api/utility/avail.linodeplans

Presumably you can select the relevant ID based on plan properties (cores, RAM, etc.) rather than hardcoding IDs. Though I completely agree that once a plan has a specific ID, as long as that plan is available the ID should be constant.

[mwpmaybe]

Yeah, that's... not practical.

What if they upgrade the 1024 plan to 1536? (That has actually happened, by the way.) Now you're extracting the number and comparing it to a range?

> Give me the plan where the RAM is >= 1024 and < 2048.

What if they upgrade the 1536 plan to 2048?

> Nevermind, just give me the plan with two cores.

Okay, do you want the $20/mo plan or the $120/mo plan?

> Fine, sort the plans by cores and memory and give me the smallest plan.

Oops, they introduced a new plan with one core and less (i.e. not enough) storage.

I'm not saying it's impossible. Just impractical.

[Sir_Cmpwn]

It's not as difficult as you're suggesting. Figure out your minimum specs and get the cheapest plan that meets them.

[ceejayoz]

Or, the API's plan IDs could correspond to specific plans, and never change. New plans mean new IDs. Like how IDs are supposed to work.

[Sir_Cmpwn]

The plans themselves have changed many times before. They become obsolete over time. What if your plan ID becomes unavailble, or the specs change in a way your application can't handle? Don't shrug off your bad design decisions on someone else.