Divergence between 16 and 19

[etobella]

Hello everyone @DarioLodeiros @jesusVMayor @max3903

I have checked this repo and I found that there is 2 major versions maintained, 16 (by Roomdoo) and 19 (by Gray Matter Logic), however I see several problems:

1- 19 is based on 14, not 16
2- I don't see PRs porting changes from 16 to 19 and viceversa
3- Base module (pms) has been renamed to pms_base in 19
4- Other modules have not been renamed on 19, so, if it was a fork, they will not be able to coexist in the future.

I see a major problem here when Roomdoo decides to migrate to a newer version.

Was all of this intended?

[DarioLodeiros]

Hi @etobella , thanks for raising this — we share the concern. cc @max3903 @jesusVMayor

Some context from our side: at Commit [Sun] we are currently working on a refactoring of the
PMS engine in 16.0, precisely to prepare a clean and stable migration path to 19.0. The
roadmap is here: #352, and we are coordinating it with Jesus Ventosinos.

Regarding the 19.0 branch: those modules come from the old 14.0 line, which is a
discontinued fork of this repo's engine. Beyond the divergence points you list, after
reviewing the 19.0 code I think there is a more fundamental issue: in my opinion those
modules are not a PMS in the operational sense — they don't provide the reservation-
management operations this vertical needs:

• The bookable unit is the whole property: pms.reservation only references
  pms.property, with a constraint that forbids two reservations on the same night at
  the same property (an entire-home/vacation-rental listing model). pms.room exists
  but is purely descriptive — reservations never reference rooms, so there is no
  room-level inventory, assignment or availability.
• There is no availability/restriction management, no daily pricing (the price is a
  static product list price per "reservation type"), no folio of its own (it delegates
  to sale orders), check-in/checkout are just kanban stage changes, and there is no
  guest data management for legal requirements, nor channel distribution.
• The remaining modules (pms_account, pms_crm, pms_project, pms_purchase,
  pms_stock, pms_website, ...) are thin bridges adding a property dimension to
  standard Odoo apps.

That approach is perfectly valid for managing a portfolio of rental properties around
Odoo's standard apps, but the hospitality operations themselves would have to be handled
outside these modules, in an external system. In other words, they complement a PMS
rather than being one. Our 16.0 line takes the opposite approach: the PMS is 100% Odoo
and covers the full operational vertical (room-level inventory and availability, dynamic
pricing, folios and payments, check-in with guest legal data, channel connectivity...),
so I believe it makes more sense to keep continuity and have 19.0 be the refactored and
migrated version of 16.0.

To be clear, these modules were merged into 19.0 without our knowledge — it may have
been announced at some point and we simply missed it, in which case apologies for not
reacting earlier.

In any case, to clean up the repository and keep moving forward, we would need a clean
19.0 branch to receive the migration of the refactored 16.0 modules — the PMS engine is
the base of this repo for the hospitality vertical. From there, we would be happy to
retake the idea of joining efforts on all these developments: the roadmap in #352 is the
base we propose to converge on, and everyone is welcome to contribute to it.

[max3903]

Hello @etobella @DarioLodeiros @jesusVMayor

Historically I contacted @DarioLodeiros and I even believe we had a call where I explained the requirements of the project I had on version 14. The architecture of the pms repo at that time was very monolithic (one big module doing too much). The decision was to coexist and converge.

We recently had an opportunity with a hotel and I didn't want to demo with version 14, so I quickly migrated the modules I knew to version 19. The solution convinced the customer but they didn't have the budget to sign.

The hospitality industry is very promising here in Mexico and I need to have a good solution next time an opportunity comes up. I believe nobody is using our 19.0 pms modules today so if we want to converge, it could be now on 19.0 or next month on 20.0.