| [jakarta.ee-spec] Version Numbering |
Hi, I’m no sure, if the “Jakarta EE Spec” list is as actively used, but I also send it CC there. Following up on the discussion about the relationship between Spec, API and TCK version numbers, I’d like to bring in experience and expectations by actual users, large companies that are currently using Enterprise Java, Spring or similar technologies and may want to use Jakarta EE over time. David mentioned, it is technically no problem to generate a new spec every time another artifact like TCK changes, be it just a rather small bugfix, but is it really in the interest of enterprise users to be “spammed” with paper and sometimes no real change between two or more versions? I don’t think it would be in the interest of developers or end users especially the larger ones, where approval to use a new technology can take many months and go all the way to corporate HQ. I also spoke to some decision makers at a current end client in the financial sector where we deal with the European regulation PSD2 (which matters at least for most countries in the European Economic Region including Switzerland, UK or other “not so EU” countries) Those in Britain may have heard of Open Banking UK or even used it. We briefly touched it, but won’t use it here, but because it is one of two major initiatives here are their specifications: https://openbanking.atlassian.net/wiki/spaces/DZ/pages/16385802/Specifications See yourself, but the version numbers look relatively uncoordinated. What we and others in Central and Eastern Europe follow is the other initiative, the so called “Berlin Group”. https://www.berlin-group.org/nextgenpsd2-downloads Its two major specs, the “Operational Rules” and “Implementation Guidelines” are each available in a 1.x version. Operational Rules defines the key Use Cases while Implementation Guidelines looks at how to apply them also with rather concrete technologies like OAuth and Open API. Since 1.2 of that document there is also an OpenAPI 3 compatible YAML file. That file saw multiple minor updates, patches and errata, but that does NOT increase the version number of the Implementation Guideline or even the Operational Rules without any change to those documents. Most integrators and end clients have not even migrated from Berlin Group 1.1 to 1.2 and a synchronization of both documents is announced within about a month. Then it will both be 1.3 again. An example of a spec that changes on average once per quarter. As the PSD2 regulation must reach a TEST stage in Q1/2019 and PROD in Q3, there is not much room for constant changes, but we may see one or the other spec upgrade before March 2019. Upgrading the specifications from 1.2 to 1.3 or even just 1.2.1 (a pattern Open Banking UK seems to use with 3 digits) with every minor patch of the YAML or other artifact would likely bring turmoil to all the companies trying to jump into the lucrative PSD2 consulting sector and even more to their end customers like banks or fintechs. This is just one example, but there are many highly regulated industries, bank, insurance, health care or public sector where the “Easy Go” mentality we see at many “Cloud Native” poster children like Netflix, Uber, SoundCloud or Zalando seems much easier to apply, or even at many FinTechs that participate in the PSD2 program, but there is no use, if say WireCard or Zalando used version 2.5 of the Berlin Group spec just because they can but 90% of their banking partners (called ASPSPs) are only supporting 1.1 or 1.2. They will have to stick to the functionality their banking partners offer even if they may provide some new and nifty features to their own end customers. I hope you get the idea from this example? Speak soon, Werner |