Suggestion for Handling Pre-Releases

[Livnat Peer]

On 01/14/2014 10:31 PM, Itamar Heim wrote:
> On 01/14/2014 07:51 PM, Livnat Peer wrote:
>> On 01/14/2014 05:26 PM, Itamar Heim wrote:
>>> On 01/14/2014 11:15 AM, Livnat Peer wrote:
>>>> On 01/13/2014 09:35 PM, Brian Proffitt wrote:
>>>>> Kiril, Dave and I were discussing how to update the community on
>>>>> pre-releases, while still keeping newer users on track to download
>>>>> and install the most stable release. What would be some suggestions
>>>>> on how to ensure new users are getting stable and veteran users are
>>>>> getting to development releases, if they want? We were pondering a
>>>>> separate link on the home page to something like this
>>>>> (http://www.ovirt.org/Download_devel_release), but other ideas are
>>>>> more than welcome.
>>>>>
>>>>> Ideally, we want to make the onboarding process as (a) efficient and
>>>>> (b) easy as possible.
>>>>>
>>>>
>>>> Brian,
>>>>
>>>> Just making sure I got the question right, we are looking on a way to
>>>> make the alpha/beta build more available for users?
>>>>
>>>> If that is the question, how about the jboss( Wildfly :) ) approach
>>>> http://wildfly.org/downloads/
>>>>
>>>>
>>>> Livnat
>>>>
>>>>> Looking forward to hearing from you,
>>>>> BKP
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Arch mailing list
>>>> Arch at ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/arch
>>>>
>>>
>>> I think Lior was talking about making this visible via the webadmin.
>>
>> That was my understanding as well.
>>
>>> I think the right way of doing this is not related to the web site,
>>> rather to the ovirt engine showing if there are newer (relevant)
>>> packages in the engine-check-update queue.
>>
>> I don't think the two are exclusive or, I think we should have both.
>> I rather d/l bits from a website over clicking on d/l buttons in the app.
>>
> 
> d/l bits from the website doesn't work for rpm based deployments for
> updates.
> the website download link should point to latest stable release, maybe
> also to latest unstable (next version alpha/beta/etc.).
> 
> the webadmin should show an existing admin that there is a newer version
> available, without the admin visiting the website.

The webadmin should indicate that there are new bits, for getting them
you need to go to the website and d/l them.

The original question was how do we add exposure to the pre-releases
which are not available today for users, and the webadmin can not be the
only way to get alpha/beta release.