Build Numbers and Windows Product Versions

[taunuscoder]

Hi,

on Windows using <maven.build.timestamp.format>yy.w.ukkmm</maven.build.timestamp.format> can lead to a timestamp 21.29.71010, (2021, week 29, Sunday, 10:00 AM) which violates the specification in https://docs.microsoft.com/en-us/windows/win32/msi/productversion, that requires a product version of not greater than maximum value of 65,535.
... hence the build fails.

(general: fantastic work --> thanks so much!!)
Peter

[wiverson]

Ha, easy fix - don't work on Sunday.

I just took a stab at tweaking the format to yy.ww.WWkkmm - testing now.

[taunuscoder]

I still see two issues (the first existed with the old format already):

1. If January 1st is a Thursday, Friday or Sunday its ISO-week number is 53 or 52! (likewise week 1 can already start in December) >> ok, one resolution again could be don't code around new years eve ... ;-)
2. Wkkmm does not produce ascending IDs within the week as W stays identical for all week days, therefore we need the 'u'.

I would only see the possibility to drop the minutes and postulate don't release twice a hour (... which in hectic error fixing periods might not be a good idea either) (ukk or as alternative DDDkk)

[wiverson]

Huh. Maybe tweak the timestamp hours/minutes portion and switch to using build numbers...?

https://docs.github.com/en/actions/reference/environment-variables#default-environment-variables

GITHUB_RUN_NUMBER looks like the best candidate. I believe it's possible to access in the pom.xml as ${env.GITHUB_RUN_NUMBER}

Thoughts?

[wiverson]

<maven.build.timestamp.format>yy.ww</maven.build.timestamp.format>
<app.version>${maven.build.timestamp}.${env.GITHUB_RUN_NUMBER}</app.version>

Kind of a strange timestamp w/only granularity of a week. Maybe this should go in a CI specific build profile activated by ${evn.CI} being set to true.

https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/text/SimpleDateFormat.html

[wiverson]

So, FWIW there were some issues around timestamps being used for upgrade versions in the earlier version of this template. In certain circumstances a timestamp was going backwards instead of fowards.

I just redid the way versions work to build on top of GitHub Action run ids instead of timestamps. I think this is closer to what everyone wants:

• Same version number for Windows, macOS, and Linux builds
• If one build fails all the builds fail
• Version numbers are now clear simple incrementing from 1 values
• Should fix the Windows timestamp-related issues

I think this means this open issue is fixed, LMK.