For the 2.0 we expected to do a lot of breaking changes (especially the new model), but due the sheer complexity to keep the retrocompatibility, I think that a more step by step approach should be considered.

A more realistic roadmap

2.0M0 DONE!

• The first step - worthy of a 2.0 release - consist in dropping mysql and hsqldb. With the availability of postgresql in basically every big cloud provider, the necessity to support others database is clearly reduced. This has already been done in the v2 branch. [PR done]
• POSTPONED: Additionally the pgsql switch, we can use the skip locked functionality where possible: this is the first step for removing the quartz scheduler and will improve the contention.
• Switch to spring boot 2 and spring 5: to keep up with spring and enjoy the new features (already done in the v2 branch). [PR done]
• POSTPONED: Integrate the new payment api: some work has already been done, need to be completed though.
• Integrate the new flow and misc works done on the https://github.com/devoxx/alf.io branch
• Switch to the new eu vat checker [PR done]

2.0M1 DONE!

• Integrate the new payment api: some work has already been done, need to be completed though.
• Import billing document feature, as developed on the https://github.com/devoxx/alf.io branch
• Update source level compatibility to JDK 11. The final v2.0 will most likely target JDK12
• use the skip locked functionality where possible: this is the first step for removing the quartz scheduler and will improve the contention. -> WIP in task Explore how to remove quartz scheduler #361
• try to drop quartz Explore how to remove quartz scheduler #361 : WIP

2.0M2 DONE!

Public side work. The goal is to reduce the maintenance burden of the current frontend and expose new venues for integration.

• A REST api for the public api
• A new frontend that use the public REST api
• Support for Strong Customer Authentication (a.k.a. 3DSecure 2.0) for credit card payments

2.0M3 DONE!

• OpenID connect support, see docs
• Support for online events, see docs
• Initial support for HTML email, see Support HTML email templates #885

2.0M4

• Support for subscriptions: sell your season passes through Alf.io
• OpenID connect support for the attendees (i.e. sign up to complete the reservation)
• Update dependencies to their latest version

2.0M5

• Update minimum JDK to 17
• Switch to Docker as reference runtime platform (this will allow us to update java version in the future without impacting too much on users)
• Remove Lombok
• Cleanup code by fixing ErrorProne warnings
• Integrate public front-end in the main repo, as a separate module/project
• Create stub for the new admin front-end in the main repo, as a separate module/project

2.0M6

Work originally planned for M3, postponed due to "force majeure"
Admin side work. The goal is to finally cleanup the admin side.

• Optimize the "get events" API for backoffice. Currently we filter the list server side, we should do it directly on the database
• New model finally integrated. Note: this could be done step by step in the 2.0-2.3 release too.
  It may be possible to do a gradual conversion.
• A new admin frontend that consume the current rest api and some new ad hoc api.
• public rest api: documented with compatibility promise
• Admin REST API.

Interesting tasks that could be done in the 2.0-2.3 timeframe:

• event archiving: add archiving functionality for past events #186
• db refactoring/semplification: unify resource_* with the configuration_* tables #400
• move all view creation in a afterMigrate scripts (see https://flywaydb.org/documentation/callbacks), so we can always drop them and recreate them (and add a beforeMigrate where we drop the views?) see move all views in afterMigrate__* scripts #479
• add social login for admin: add "social" login #301
• see all the 2.0 related issues: https://github.com/alfio-event/alf.io/milestone/13
• try to make true the "waiting queue" centric design
• a better way to load fonts for the pdf generation (should we add other fonts in the docker image?)
• email handling: instead of processing them in bulk, use select for update skip locked for a single row + use pgsql notify on creation of the mail, the first instance that will be able to select will send the email + job for the remaining one in case of failures
• support svg upload now that we can render them in the pdf (see Jpeg or png allowed to upload but svg not #97)