Bug 1400072

Summary: udpater notifier for windows msi is should have major version in url
Product: Red Hat Enterprise Linux 7 Reporter: jiri vanek <jvanek>
Component: java-1.8.0-openjdkAssignee: Alex Kashchenko <akashche>
Status: CLOSED CURRENTRELEASE QA Contact: BaseOS QE - Apps <qe-baseos-apps>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.4CC: akashche, dbhole, jvanek
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Windows   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-12-14 15:29:13 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On: 1400066    
Bug Blocks:    

Description jiri vanek 2016-11-30 12:02:39 UTC
W mostly support only udpates in space of single major jdk (eg jdk8 v1 -> jdk8 v2, not jdk8 v2->jdk9 v1)

Exempalr url of is now: https://raw.githubusercontent.com/ojdkbuild/scratch/master/rhtemporary/version.json

Although this file contains pacage name (java-1.8.0-openjdk), the structure of this file is nowhere documented.

Once both jdk8 and 9 willbe supported on wndows, they will share this file.

Obvious solution is to have
https://raw.githubusercontent.com/ojdkbuild/scratch/master/rhtemporary/09/version.json
https://raw.githubusercontent.com/ojdkbuild/scratch/master/rhtemporary/08/version.json

or
https://raw.githubusercontent.com/ojdkbuild/scratch/master/rhtemporary/version09.json
and
https://raw.githubusercontent.com/ojdkbuild/scratch/master/rhtemporary/version08.json


If this mechanism will be implemented in version.json itslef, i'm not against. But again would be nice to have this information written.

Comment 2 Alex Kashchenko 2016-11-30 12:30:35 UTC
This depend on RH server-side deployment mechanism (whether URL will include actual file name or not), it is currently called "version.json" because it will be saved locally with this name.

The name for generated file can be fully-qualified:

java-1.8.0-openjdk-1.8.0.111-1.b15.redhat.windows.x86_64.json

Lets wait for the info about deployment first though.

Comment 3 jiri vanek 2016-11-30 13:03:18 UTC
+1 for "somehow" qualified. But having version+release it in may be contraproductive. Having arch in it may be even wrong.

Sure. The RH deployment must be stated first.

Comment 6 jiri vanek 2016-12-02 12:56:04 UTC
Sorry, full version is no go. By doing so, you will kill to possibility to skip update. Can you please only major as was originally bugged?

Comment 7 Alex Kashchenko 2016-12-02 13:08:40 UTC
(In reply to jiri vanek from comment #6)
> Sorry, full version is no go. By doing so, you will kill to possibility to
> skip update. Can you please only major as was originally bugged?

Agree with this, the above comment is about build-time version.json generation in the way that each such json file can be traced back to the Brew build (probably that comment doesn't belong to this thread). 

Maybe qualified name without update part will suffice for URL: 

java-1.8.0-openjdk.redhat.windows.x86_64.version.json

OS and arch are there as other OSs and archs can appear in theory.

The whole thing is a bit theoretical though until deployment details will be clear (what control we will have over url).

Comment 8 jiri vanek 2016-12-02 13:46:53 UTC
(In reply to Alex Kashchenko from comment #7)
> (In reply to jiri vanek from comment #6)
> > Sorry, full version is no go. By doing so, you will kill to possibility to
> > skip update. Can you please only major as was originally bugged?
> 
> Agree with this, the above comment is about build-time version.json
> generation in the way that each such json file can be traced back to the
> Brew build (probably that comment doesn't belong to this thread). 
> 
> Maybe qualified name without update part will suffice for URL: 
> 
> java-1.8.0-openjdk.redhat.windows.x86_64.version.json
> 

sounds good to me.

> OS and arch are there as other OSs and archs can appear in theory.
> 
> The whole thing is a bit theoretical though until deployment details will be
> clear (what control we will have over url).

I think we wil have 100% control about huge part of url. So it is not theoretical. We have to tell them where we wont it and why.

Comment 9 jiri vanek 2016-12-12 08:24:54 UTC
This bug is checked in checkers testsuite