Dates are not used as "build markers" but as actual version numbers. It is not that uncommon, The date is stored in a file version.txt and in the tag so the build is always reproducible with the version number.
The use of dates as version numbers is not that uncommon. I have seen this in Amazon and Azure API spes, in Zig numbers and in many other places. They are convenient as they can be generated automatically. Note they are used when the semantic part is already determined (0.1.2 is defined) and only marks a progression for snapshots or wehn, like in runtimes, given a fixed version (the language version) we need to distinguish progressions that are generally related to updating the libraries inside the runtime but no general semantic changes. Michele Sciabarra | CEO m: +44 747 984 8388 e: mich...@nuvolaris.io l: https://linkedin.com/in/msciab Nuvolaris Inc | 1209 Orange Street , Wilmington DE www.nuvolaris.io [image: linkedin icon] <https://www.linkedin.com/company/nuvolaris-io> [image: youtube icon] <http://bit.ly/nuvtube> [image: twitter icon] <https://twitter.com/NuvolarisIo> On Thu, 1 Aug 2024 at 20:31, pjfanning (via GitHub) <g...@apache.org> wrote: > > pjfanning commented on issue #30: > URL: > https://github.com/apache/openserverless/issues/30#issuecomment-2263709968 > > I don't like the date in the version. Reproducible Builds are becoming > the norm and having the date popping into the version number or getting > compiled into binary artifacts is an issue. > > > -- > This is an automated message from the Apache Git Service. > To respond to the message, please log on to GitHub and use the > URL above to go to the specific comment. > > To unsubscribe, e-mail: dev-unsubscr...@openserverless.apache.org > > For queries about this service, please contact Infrastructure at: > us...@infra.apache.org > >
