Suggestion for Handling Pre-Releases

[Lior Vernia]

Well, as we wish. Probably alongside, because releases have to be noted
in the official website (of any product in the world, not oVirt
specifically). I'm just suggesting a general way in which existing users
could get information about releases in a "push" manner rather than by
polling the website (I'm assuming many users are not subscribed to
mailing lists); specifically it could also easily be used to distinguish
between pre-release and stable versions (color coding, and/or when
announcing a pre-release also announce the following stable release,
and/or...).

On 13/01/14 22:38, Brian Proffitt wrote:
> Just to get a little more detail... would this be in place of announcements on the wiki page/oVirt site, or alongside?
> 
> BKP
> 
> ----- Original Message -----
> From: "Lior Vernia" <lvernia at redhat.com>
> To: "Brian Proffitt" <bproffit at redhat.com>
> Cc: arch at ovirt.org
> Sent: Monday, January 13, 2014 2:51:17 PM
> Subject: Re: Suggestion for Handling Pre-Releases
> 
> Hey Brian,
> 
> This might be far fetched, but what about having a small notification
> panel in the top part of the webadmin GUI giving information about
> upcoming releases?
> 
> This could be refreshed periodically or triggered by a "Check for
> Updates" button.
> 
> It would be fairly easy to reach most oVirt users this way, and not
> necessarily only supply the updates, but also information about release
> dates as soon as they're known, while distinguishing between stable and
> alpha/beta releases.
> 
> Yours, Lior.
> 
> On 13/01/14 21:35, 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.
>>
>> Looking forward to hearing from you,
>> BKP
>>
>>