Ticket 3.x is in planning and early development stages. **Goal** Deliver a v3 to support the Event 3.x and Commerce 3.x ecosystems. **Scope** - Event 3.x integration - Registration 3.x integration - Optional Commerce 3.x integration - Management of different ticket types, costs etc. - Migration path from Ticket 1.x to 2.x to 3.x - Migration path from Event_Ticket - Compatibility testing with Event_Group and GEvent (Group_Event) **Not In Scope** - Sub-event ticketing / Micro-ticking - Migration path from Commerce_Ticketing - Migration path from Commerce_Registration - Migration path to Registration - Scheduling / Booking / IT Ticketing - Account / User Integrations or Features This issue is now open for comment. **Background** From @richgerdes: > Currently there are 3 projects. First event , which provides a fieldable "Event" Content Entity types (not a node bundle), so that you can have multiple types of events, dedicated methods, etc. Second is event_registration , which provides the idea of registering. Registrations are free, and can be created via a form or purchased (via the event_ticket module. event_ticket depends on commerce and provides a "purchasable" entity type, registration checkout flows, and a few other commerce extensions.  I chose to make these separate modules so simple projects didn't need to bring in all of commerce to have free event registrations. > > Currently we're working on refactoring somethings for the Member Platform and CRM ecosystems, and merging event_registration with registration. The main difference is that registration allowed users to register for any "Entity" (Node, group, etc) while event_registration allowed any entity (node, group, etc) to be registered for event entities. We're merging these to allow registration of any entity for any entity (user for group, group for event, node for node, crm contact for event, etc). Once that lands, event_ticket will be refactored to support purchasable tickets for any entity type. > > So as far as how it compares to ticket , It looks like ticket provides registrations and tickets, but no commerce integration. I would say that if its being rebuilt, it could replace event_ticket the way registration is replacing event_registration . My recommendation  would be to rebuild ticket around registration to not recreate the wheel, but I don't know what that does for complexity. As far as overlap with event_ticket , I think beyond the ticket number and registration, the main difference is the commerce integration. That may or may not be in scope for the ticket module, but my version extends the purchasable entity type so its required. > > Note: There is also commerce_ticketing which is unrelated and uses product_variations as the purchasable entity. There is probably a world where this module handles commerce and the purchasable entity ticket tracks the ticket numbers optionally linked to registration's registrations. which could then be linked to event's "Event" entity, events' (different module) Event node content types, groups, or whatever other entity you want. > > I would be open to collaborating and sunsetting event_ticket in favor of ticket if you want to, but the main requirement for it was around commerce and the ability to manage different ticket types (which might have different costs, permissions, quantities, etc). Happy to meet sometime and go over it. Let me know if you have any questions.