Publishing events is a good way to advertise what is happening in your organisation and, when done correctly, allows people to add the information to their personal calendars.
Simply providing an html, pdf or other format list of events is the least useful approach. It is relatively easy (perhaps easier) to use a calendar client to maintain a single calendar collection which can be exported or published for subscription or download. Not doing so forces your users/customers to transcribe the information to get it into their calendar.
Not huge duration - recurring - allday
A subscription is generally provided using the de-facto webcal scheme, e.g. webcal://example.org/mycalendar.ics. Such a url is used by clients which will repeatedly check for changes to the data. This allows you to add new events and update or cancel existing events.
A download is usually just a one time operation - the client will import the event or events but will not go back to check for changes.
It is almost always bad practice to delete an event that is canceled. This leaves no record for people who may have decided to attend. Use the STATUS property and set it to “CANCELLED” (that’s the spelling). Clients will often highlight canceled events and it provides a positive indication to the end user.
Remember that your audience doesn’t necessarily have the full context. Put a full address into the location. Many clients will recognize it as such and use that to link to maps to help people get there. “Room 123” is simply not enough.
Ensure correct usage of the UID property. An event (including all intstances for recurring events) is identifid by the UID. When regenerating an ics feed the UID for a given event must not change.