[Libosinfo] [PATCH 2/5] Add an optional 'is-continuous-snapshot' tag to OS entries

[Zeeshan Ali (Khattak)]

On Mon, Nov 25, 2013 at 2:32 PM, Daniel P. Berrange <berrange at redhat.com> wrote:
> On Mon, Nov 25, 2013 at 02:26:13PM +0000, Zeeshan Ali (Khattak) wrote:
>> On Mon, Nov 25, 2013 at 2:11 PM, Daniel P. Berrange <berrange at redhat.com> wrote:
>> > On Mon, Nov 25, 2013 at 02:01:16PM +0000, Zeeshan Ali (Khattak) wrote:
>> >> On Mon, Nov 25, 2013 at 1:49 PM, Daniel P. Berrange <berrange at redhat.com> wrote:
>> >> > On Thu, Nov 21, 2013 at 05:52:54PM +0000, Zeeshan Ali (Khattak) wrote:
>> >> >> Applications can use this to determine if an OS is just a snapshot and
>> >> >> not an actual released product yet. For example, gnome-continuous images
>> >> >> for development snapshots of GNOME and nightly build ISOs of Fedora etc.
>> >> >
>> >> > Hmm, hang on, this is getting confusing now.
>> >> >
>> >> > My understanding was that the GNOME continuous images were officially
>> >> > released products, not development pre-release snapshots.
>> >>
>> >> I think it was the other way around. :)
>> >>
>> >> * pre-release examples: Fedora X alpha/beta and GNOME 3.9.91/2 ISOs.
>> >> * continuous snapshot examples: Fedora nightly ISOs and GNOME continuous images.
>> >>
>> >> So yeah, they are different and now we have already code/api that
>> >> differentiates both.
>> >
>> > That's not the way I was imagining it though ! When I read 'continuous'
>> > I was believing that reflected a GNU Arch/Gentoo style continuous rolling
>> > release. The idea is that before now the 'release-date' would implicitly
>> > tell you when an OS was "GA" ready, but that isn';t availble for rolling
>> > releases, hence the 'is-continuous' tag would help you there. The
>> > classification you've described though means we still have the hole
>> > around the Arch/Gentoo rolling release model.
>>
>> Sorry I don't understand the difference with gnome-continuous case.
>> Could you please point it out for me?
>
> An Fedora rawhide/GNOME continuous nightly snapshot is an unstable,
> eats babies kind of thing.
>
> An Arch/Gentoo rolling release is positioned as production quality.

Ah ok, thanks. A graphic example helps :)

>> > I think perhaps we've been looking at this wrong and what we really should
>> > have is an enum 'status' field, rather than multiple booleans
>> >
>> >   <status>snapshot|prerelease|released</status>
>> >
>> > Where
>> >
>> >  snapshot == nightly builds / automated code snapshots
>> >  prerelease == formal alpha/beta/rc like releases
>> >  released == final cut releases
>>
>> That is giving the same info to apps as the booleans. We got two
>> booleans for snapshot and prerelease and absence of both means a
>> 'released' OS.
>
> I think that having it be an enum would be better since it makes
> it more explicit / clearer IMHO

Hmm.. sure. I'll rework the patches then. :)

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124