It is not clear if your team is doing production support or software/ app dev. Assuming it is app dev, there are a few questions to consider -
What is the customer's need for the releases your team is making? If there is no pressure from customer to do a release or if the pressure is sporadic or infrequent, then there is nothing much your team can do about it. However, over longer periods of time, across multiple customers, if your team is - or becomes - challenged with having to maintain multiple versions of your product, there is a cost to that. It is then up to them - or some business function like sales or support - to have the conversation with your customers that they need to accept new releases at a certain frequency or they may be at a risk of not getting the support they might need on an old version of the product.
Is there an internal stakeholder - such as Product Owner or Sales or Management - who anyway needs to see what work the team has competed - and done so satisfactorily - at least from a quality and market requirements perspective? If yes, it might be worthwhile for them to deploy new or updated code to an internal staging/ demo server so they can do demos to your stakeholders - or let them get their hands dirty and help validate the new/ updated features of the product.
If it is a production support environment, there may be some SLA (service level agreement) goals to be met (response time, resolution time, etc.) - which would again need some pre-defined frequency of releases in order to meet those SLAs. Again, without more information, it would appear your team is not facing SLA violation issues and unhappy customers.
Based on these, there certainly are guidelines for you to follow about how to model your Kanban board so it matches your current business processes - and helps you improve, as Daniel pointed out above.
WIP Limits are meant to encourage people to finish work at hand before taking up new stuff. If these are not implemented, you might have a situation where half-done tickets lie around in intermediate in-progress or done stages waiting for some external dependency (customer input, shared resources, etc.) and the team, instead of resolving them, takes up new tickets. Pretty soon, you can have a slow-moving Kanban board with low flow and throughput and high lead times.
Instead of calling the last column "waiting for release", it could simply be better named - either "Deployed to Staging" or just "Completed" - so it is clear to everyone concerned that no more work is pending other than putting it out in a release.
However, just to be clear - Kanban is not prescriptive in nature - and it simply asks you to start with what you have - and look for improvement opportunities. If your unpredictable release schedule is a (perceived) problem, it can be easily fixed by defining an explicit policy to do releases every 1, 2 or 4 or 6 weeks, whatever is acceptable in the business context. If it is not, and everyone knows what "Waiting for Release" means, there's no need to change anything!
I'd like to share the example of our own Dev team (we are a Kanban product developer - SwiftKanban), which has a somewhat similar situation. We have both SaaS and on-prem customers. We do SaaS releases every 4-6 weeks - that cadence is well established. But, our on-prem customers may take new releases as late as once in 3 months only - and we have little control over that - it is really based on their own cost of deploying a new release from a vendor.
So, we follow a process similar to what I described above - and this is what our Kanban board looks like -

As you might be able to tell, our internal staging server (just to the left of the green Production column) is Ganesha - and we deploy new features, bug-fixes and other enhancements on a fairly continuous basis. This server is used as an "internal production" server where we run our company operations - such as Marketing, HR, etc.
So, cards sitting in the Ganesha column are cards that are done and deployed. We have no WIP Limit here - but our policy is to deploy a new release to production when we have approximately 20 items completed. All other columns on the board have WIP limits as needed - based on the number of people working on each stage.
Like I said, we deploy to our SaaS production regularly every 4-6 weeks. Our customers can take up new releases every 1-3 months whenever they are ready. So you could easily set a WIP limit on a similar column and use that limit to ensure that the team deploys to production when the WIP Limit has been reached. It is really up to your team and your customers as to what makes sense!
Hope this helps.