Hide Forgot
The descriptor file of for update_checker lookslike this: { "package_name": "java-1.8.0-openjdk", "package_description": "OpenJDK runtime", "os_name": "Windows", "os_arch": "x86_64", "version_string": "1.8.0.111-3.b15", "version_number": 81113, "ui_balloon_text": "OpenJDK version 1.8.0.111-3.b15 is available for download.", "ui_update_header": "OpenJDK version 1.8.0.111-3.b15 is available for download", "ui_update_text": "This version contains a number of security fixes.\n\nTo proceed with download and installation please follow a link above, download page will be opened inside your web-browser.\n\nTo change a schedule of this notification please see 'RedHat_jdk_update_checker' and 'RedHat_jdk_update_notifier' tasks in 'Task Scheduler'.\n\nTo disable this notification permanently please select the installed appplication in 'Programs and Features' with a right-click, choose 'Change' and disable 'Update Notifier' installation feature." } The main string is "version_number": 81113, Assuming it goes from 1.8.0.111-3 it is very week. 1.8.0.111-14 although < 1.8.0.112-1 will fail (811114>81121) although should not. In same 1.9.0.01-1 will fail with 1.8.0.112-1 as 9011<81121 although should be higher Instead of int, proepr version sort shold be included, or at elast do a bulelt proof int (..long) which will align zeroes to eg: 1.8.0.111-4 -> 1080111004
Longer version number fine for me (if it fits into int32_t), will change "shipped version" in notifier to this format in next builds and will update test version.json files on github.
Also, can the current set up be extended to multiple major version checks e.g. if I have only 8 or only 9 installed, vs both, etc.? If now, can we just use major version (so that update check checks for installed X major version updates only) + build date/time for verifying? That way we don't have to worry about version weirdness and length.
I'd rather avoid time here due to timezones, but if we add two more digits to the date instead of time (to have up to 100 builds for a single date) and cut the two digits from year (so we fit in int32 and are safe until 2100) we've got: 816112801 If there won't be objections, I'll go with this variant.
(In reply to Alex Kashchenko from comment #3) > I'd rather avoid time here due to timezones, but if we add two more digits > to the date instead of time (to have up to 100 builds for a single date) and > cut the two digits from year (so we fit in int32 and are safe until 2100) > we've got: > > 816112801 > > If there won't be objections, I'll go with this variant. So the last 01 here is the hour of the build? I am fine with that; it is not intended to be externally understandable, and we are almost certainly not going to release builds built within 1 hour of each other. As long as it is documented in code and design docs, +1 to this. It will be interested to see if Java apps generally suffer from the same issues Windows apps did when Windows went to Win 10, but we should assume it wont and proceed as though next version will be 11.
01 postfix in these scheme will be not an hour, but a serial number between the up too 99 builds released on that day (quite small difference with an hour actually, just it will be "01" in majority of cases).
Hmm, might be easier to make it hour (assuming the json is auto-generated).. that'd take away possibility of human error (and the need for human intervention for version string).
It is currently not autogenerated (and not going to be in this release) so I'll just use 01 (that is still a valid hour) for manual versions. And hour can be used in future.
(In reply to Alex Kashchenko from comment #7) > It is currently not autogenerated (and not going to be in this release) so > I'll just use 01 (that is still a valid hour) for manual versions. And hour > can be used in future. Sounds good!
(In reply to Alex Kashchenko from comment #1) > Longer version number fine for me (if it fits into int32_t), will change > "shipped version" in notifier to this format in next builds and will update > test version.json files on github. Why int32? what tops int64? Also is this generated? If not theen it is showstopper. Error of the length of this string caused many issues in rpms. I do not wont to fall to same trap.
(In reply to jiri vanek from comment #10) > Why int32? what tops int64? Current uin32_t is used for this field, so only format itself needs to be changed without code changes. AFAIU jansson will support int64_t fine if that will be required - https://jansson.readthedocs.io/en/2.4/apiref.html#json_int_t > Also is this generated? If not theen it is showstopper. Error of the length > of this string caused many issues in rpms. I do not wont to fall to same > trap. It is not generated now, but going to be in future. I'd like to add version.json to the list of Brew artifacts for each build ( as CHANGES.txt here https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=517058 ). We will need some facilities to obtain formatted current date in CMake environment (there are no ways to do so in cmd.exe), I think about integrating shell_helper utility ( https://github.com/akashche/shell_helper#time ) there. But that is not planned for current release.
(In reply to Alex Kashchenko from comment #11) > (In reply to jiri vanek from comment #10) > > Why int32? what tops int64? > > Current uin32_t is used for this field, so only format itself needs to be > changed without code changes. AFAIU jansson will support int64_t fine if > that will be required - > https://jansson.readthedocs.io/en/2.4/apiref.html#json_int_t int32 is some 4 000 000 000 right? Thast enough, but closely! 1 08V VVB VV? I'm not exactly fan of the version suggested above, but looks like it doesnt metter. Both provide bigger ID for later builds. *however* Both are suffering from leading zeroes time 2016:02:22:01 as 816222XY may ge lower then 2016:03:03:05(81633XY)... Jsut dont forget it. Also I would recommend preixing by 108 for 8 109for nine nad 110 for 10. Keeping fixed length *is* benefit. > > > Also is this generated? If not theen it is showstopper. Error of the length > > of this string caused many issues in rpms. I do not wont to fall to same > > trap. > > It is not generated now, but going to be in future. I'd like to add > version.json to the list of Brew artifacts for each build Thax. Is really necessary.
(In reply to jiri vanek from comment #12) > int32 is some > 4 000 000 000 right? Thast enough, but closely! > 1 08V VVB VV? Currently it is (comparing to max uint32): 816121301 4294967296 > I'm not exactly fan of the version suggested above, but looks like it doesnt > metter. Both provide bigger ID for later builds. > *however* > Both are suffering from leading zeroes > time > 2016:02:22:01 as 816222XY may ge lower then > 2016:03:03:05(81633XY)... > Jsut dont forget it. Currently no leading zeros are stripped, only first two digits of year are stripped. > Also I would recommend preixing by 108 for 8 109for nine nad 110 for 10. > Keeping fixed length *is* benefit. I tend to agree, at the same time we can safely make it longer for the following versions, but cannot make it shorter. So I propose to keep the "8YYMMDDXX" format for this release and change it (to int64) in the following versions if new format will appear to be more convenient.
> > > Also I would recommend preixing by 108 for 8 109for nine nad 110 for 10. > > Keeping fixed length *is* benefit. > > I tend to agree, at the same time we can safely make it longer for the > following versions, but cannot make it shorter. So I propose to keep the > "8YYMMDDXX" format for this release and change it (to int64) in the > following versions if new format will appear to be more convenient. Why not to do it now?
(In reply to jiri vanek from comment #14) > Why not to do it now? Current variant works, format is generally agreed and can be changed (extended) later. New variant is not yet agreed and will require code changes for int64.
(In reply to Alex Kashchenko from comment #15) > (In reply to jiri vanek from comment #14) > > Why not to do it now? > > Current variant works, format is generally agreed and can be changed > (extended) later. New variant is not yet agreed and will require code > changes for int64. The software was never released, so it is better to do it in first release then in some later creepy update. Jdk 10 wil be there in 6 years. It will be probaboy another person workin on that combination. So can you please add 108 prefix and move to int64 if it no longer fits to int32? From all you are sying it will work fine. So really do it now before we do firts public release.
(In reply to jiri vanek from comment #16) > So can you please add 108 prefix and move to int64 if it no longer fits to > int32? I'll change the handling of this value to int64 so old (shipped) versions will supports (possibly extended) new format (this bit is overlooked in Comment 13). As we can make format longer in future, but cannot make it shorter, I think we should go with the current one. If a new one will be agreed - we will switch to it in following versions. About "108" prefix - what problem will it solve? Currently prefix is "8", we can have prefixes "9" and "10" for the following versions without changing the format.
(In reply to Alex Kashchenko from comment #17) > (In reply to jiri vanek from comment #16) > > So can you please add 108 prefix and move to int64 if it no longer fits to > > int32? > > I'll change the handling of this value to int64 so old (shipped) versions > will supports (possibly extended) new format (this bit is overlooked in > Comment 13). As we can make format longer in future, but cannot make it > shorter, I think we should go with the current one. If a new one will be > agreed - we will switch to it in following versions. > > About "108" prefix - what problem will it solve? > > Currently prefix is "8", we can have prefixes "9" and "10" for the following > versions without changing the format. It will ensure fixed length of the number. I do not insists on it, but I think it is good precaution.
(In reply to jiri vanek from comment #18) > It will ensure fixed length of the number. I do not insists on it, but I > think it is good precaution. Fair point, but it will also make the version longer (thus limiting its changes in future), so I'd keep the existing scheme for now.
(In reply to Alex Kashchenko from comment #19) > (In reply to jiri vanek from comment #18) > > It will ensure fixed length of the number. I do not insists on it, but I > > think it is good precaution. > > Fair point, but it will also make the version longer (thus limiting its > changes in future), so I'd keep the existing scheme for now. Which will have the fixed length anyway.... Be sure our sucecssors on jdk10 will faec breakage on this decission.
Btw this is the same point as with swithces. It is bringing no issue, it si making the concept more solid, but because "you already did it" (or I really dont understand why) you are refusing to change it.
(In reply to jiri vanek from comment #21) Unless version format breaks the comparison (and no sensible variant will) I don't see the particular format as important feature or as a feature that can affect app stability. Please agree new format with Deepak (we have ack for existing one) - I will implement it after that.
Jiri, not sure if I am not seeing something here -- what is the issue with <major><major>YYMMDDHH format? it allows us upto 41 major versions minimum before we would need to expand to 64 bit. I understand the need for a fixed length on RPM, but here we are not dealing with rpm releases and minor versions (which is what led to problems, compounded by the fact that we don't control alternatives determination logic). Do you see a case where we would run into a breakage before version 41 at the least?
<major><major>YYMMDDHH would be fine But what I see in examples is <major>YYMMDDHH My point s - why dont do it now, while it is not yet release? Why to wait when it get broken? Unless there is 1399644 fixed, I bet some zero will fly in or out. So I would like to be pretty sure (check on length) that id did not.
(In reply to Alex Kashchenko from comment #5) > 01 postfix in these scheme will be not an hour, but a serial number between > the up too 99 builds released on that day (quite small difference with an > hour actually, just it will be "01" in majority of cases). Is this automatable at all?
(In reply to jiri vanek from comment #24) No objections to change it for this release (and I'd also like to have 1399644 implemented this week too unless something urgent will appear). > <major><major>YYMMDDHH would be fine Proposing the following as a final format: <major><major>YYYYMMDDHH Where <major><major> will be "08", "09", "10" and so on. (In reply to jiri vanek from comment #25) > Is this automatable at all? Will use an hour in automated variant.
(In reply to Alex Kashchenko from comment #26) > (In reply to jiri vanek from comment #24) > > No objections to change it for this release (and I'd also like to have > 1399644 implemented this week too unless something urgent will appear). > > > <major><major>YYMMDDHH would be fine > > Proposing the following as a final format: > > <major><major>YYYYMMDDHH > > Where <major><major> will be "08", "09", "10" and so on. This is nice. But when int is done from the string, leading 0 is rmeoved. So we are back on <major>. > > (In reply to jiri vanek from comment #25) > > Is this automatable at all? > > Will use an hour in automated variant. hm.. I do not feel exactly safest abut it. If you accidentlaly bulid two builds in hour. Yes, only one will go to production. But the id inside will be same.
(In reply to jiri vanek from comment #27) > > <major><major>YYYYMMDDHH > > > > Where <major><major> will be "08", "09", "10" and so on. > > This is nice. But when int is done from the string, leading 0 is rmeoved. So > we are back on <major>. > > [...] > > If you accidentlaly bulid two builds in hour. Yes, only one will go to > production. But the id inside will be same. M, and what are your suggestions on both of these points? Both points look valid, but I am not sure how important are they as the only hard requirement to this version number is that integer comparison must continue working.
(In reply to Alex Kashchenko from comment #28) > (In reply to jiri vanek from comment #27) > > > <major><major>YYYYMMDDHH > > > > > > Where <major><major> will be "08", "09", "10" and so on. > > > > This is nice. But when int is done from the string, leading 0 is rmeoved. So > > we are back on <major>. > > > > [...] > > > > If you accidentlaly bulid two builds in hour. Yes, only one will go to > > production. But the id inside will be same. > > M, and what are your suggestions on both of these points? > For this one is the one I keep repeating since beginning "1<major><major>" The leading zero also allow to bump..epoch.. If necessary. > Both points look valid, but I am not sure how important are they as the only > hard requirement to this version number is that integer comparison must > continue working. there is one ore case - to prevent that human error will not bubble up to customemr and if human error passes build checks, it will be catch at QE. For second the only solution is to use NVR as linuxbuilds does. But Idont know how widnows builds does. So maybe holly grail may be: 1<maj><maj>YYMMDD<ver><ver><ver><build><build><build><release><release> But only if the single number you hardcode is understand by brew (so it will not allow second same build) and propaagted to name of pkg and to the id in version.json But in that case the timestamp is loosing sense anyway. I feel myself on edge of overengineering so if You come with something better I will be happy.
(In reply to jiri vanek from comment #29) > For this one is the one I keep repeating since beginning "1<major><major>" Got it, +1 to this. > For second the only solution is to use NVR as linuxbuilds does. But Idont > know how widnows builds does. Current Brew NVR: name = openjdk8-win version = 1.8.0.111 release = 1.b15 > So maybe holly grail may be: > 1<maj><maj>YYMMDD<ver><ver><ver><build><build><build><release><release> > > But only if the single number you hardcode is understand by brew (so it will > not allow second same build) Brew probably won't allow two non-scratch builds with the same NVR. > But in that case the timestamp is loosing sense anyway. Lets drop it then: 1<maj><maj><update><update><update><build><build><build><release><release> 10811101501 Can we go with this one? > I feel myself on edge of overengineering so if You come with something > better I will be happy. The whole thread looks a bit like bikeshedding to me (int32 -> 64 was important though), but I think it is better to have some final futureproof scheme here to not return to it later.
> The whole thread looks a bit like bikeshedding to me (int32 -> 64 was > important though), but I think it is better to have some final futureproof > scheme here to not return to it later. Bikeshedding right? Go on with your original buggy: > Assuming it goes from 1.8.0.111-3 it is very week. > 1.8.0.111-14 although < 1.8.0.112-1 > will fail (811114>81121) although should not. then
uint64_t changeset: https://github.com/ojdkbuild/contrib_update-notifier/commit/718fe89444341290d1bbfc41d3ba3ee2286e586b version generation details: template: https://github.com/ojdkbuild/contrib_update-notifier/blob/master/resources/version.json notifier changeset: https://github.com/ojdkbuild/contrib_update-notifier/commit/04121d4859375e668ad05e67e01828064f8936c2 parent changeset: https://github.com/ojdkbuild/ojdkbuild/commit/abe805c2d034e7a59344ac54dac7c78eb62c15b1
(In reply to Alex Kashchenko from comment #33) > uint64_t changeset: > https://github.com/ojdkbuild/contrib_update-notifier/commit/ > 718fe89444341290d1bbfc41d3ba3ee2286e586b > > version generation details: > > template: > https://github.com/ojdkbuild/contrib_update-notifier/blob/master/resources/ > version.json > notifier changeset: > https://github.com/ojdkbuild/contrib_update-notifier/commit/ > 04121d4859375e668ad05e67e01828064f8936c2 > parent changeset: > https://github.com/ojdkbuild/ojdkbuild/commit/ > abe805c2d034e7a59344ac54dac7c78eb62c15b1 What is the string doing to look like now?
The one that was generated during the last build: 10811101502
Sorry for digging into it again. I just noted: 10811101503, <_OpenJDK version 1.8.0.111-3.b15 there seems to be inverted 15 and 3 in those strings is it intentional? if yes, it is buggy (imo) 4.15 should be higher version then 3.16 but will not be udpated as 154 si < 163 (I know that RPM's release.build is complete nonsense and hope to fix it for jdk9)
(In reply to jiri vanek from comment #38) > 4.15 should be higher version then 3.16 IMO, that cannot happen (at least not to jdk8), newer upstream sources (b16 > b15) should always take precedence over our internal "rpmbuild" - "-4" and "-3". Also, we can swap these fields in future any time when "update" version will be incremented.
In rpms we can not simply swap them, and the versioning of rpms and win should be aligned. And although I agree that the case should not happen, it can happen (==will happen) So as you can not change X.bY to correct bY.X (as you will diverge from rpms) you really should align the int to the real versionning string.
So the resulting version number will be the following? 1<maj><maj><update><update><update><release><release><build><build><build>
As in rpm world the release is relase.bBuild I'm afraid it will be. Again apologise for not spotting it earlier, as n rpm world the build is part of release. (btw if you think that the bug *can* *not* I'm not going to force you into this)
This should do the trick - https://github.com/ojdkbuild/ojdkbuild/commit/1c062a286ae6da6ac89543dafceeafa3d5f0a1bb Not yet tried - started scratch build; also updated versions in github tmp repo
Tested i checker testsuite