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@xxxxxxxxxx> 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@xxxxxxxxxx> 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. Clearly two very different types of OS. > > 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 Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| _______________________________________________ Libosinfo mailing list Libosinfo@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libosinfo
