I think we need to let each SDAP component that has its own repo to have its own version number that is distinct and independent from the overall SDAP release version number. As you mentioned, that way each component can have a version number that is appropriate and indicative of its maturity. Also, if a component has the same version number from one SDAP release to the next, one can be assured that component hasn't changed in that time frame.
For components and the overall SDAP, we should consider using Semantic Versioning (https://semver.org/). If we have two components, A and B, and B gets an API change that is not backwards compatible, it might get a bump in the major version number (first digit of the version for B). Component A would likely need to be updated to be compatible with the new B, but that could require just a minor change in A (so maybe we update the 2nd digit of the version for A). Also, the major update to B might be inconsequential or minor at the system level API so if we cut a release, it might have a minor version update. Joe On 2023/09/20 15:50:03 Riley Kuttruff wrote: > Hi everyone, > > As mentioned during yesterday's meeting, the versioning strategy for > new/infrequently released components needs discussion/finalization. > > Components such as NEXUS and ingester are updated frequently enough that this > isn't an issue for them. However, nexusproto and potentially new components > such as insitu data services pose a potential problem. > > The simple solution would be to version each updated component to match the > SDAP release version. For example, nexusproto's latest released version is > 1.0.0. Should it be updated in 1.3.0 (which is almost certain), it's version > will go from 1.0.0 to 1.3.0. The issue with this is, when new components are > released, they will be versioned as mature code. On the other hand, not using > a strategy like this would require us to keep track of all the differing > versions of our various components each release cycle. Perhaps we could adopt > a hybrid approach, with new components having versions like 0.x.x until we > deem them mature enough to "catch up" with the rest of the components. > > I'd like to open this to discussion so maybe we can work out a formal method > and put it to a vote. (Is there a process for voting for one of a set of > choices, or is it just yes/no?) > > - Riley >
