Bug 1400072 - udpater notifier for windows msi is should have major version in url
Summary: udpater notifier for windows msi is should have major version in url
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: java-1.8.0-openjdk
Version: 7.4
Hardware: Unspecified
OS: Windows
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Alex Kashchenko
QA Contact: BaseOS QE - Apps
URL:
Whiteboard:
Depends On: 1400066
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-11-30 12:02 UTC by jiri vanek
Modified: 2016-12-14 15:29 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-12-14 15:29:13 UTC
Target Upstream Version:


Attachments (Terms of Use)

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


Note You need to log in before you can comment on or make changes to this bug.