Hey, folks. This is kind of a 'philosophical' side-note on versioning that comes out of my work on the release validation stuff, wikitcms, and fedfind. It's quite detailed so skip it if you like :) But I wanted to at least write it down somewhere for future reference. Those following the relval/wikitcms/fedfind/openqa work may find it useful. While gluing openqa to fedfind to python-wikitcms to relval, I seemed to keep running into cases where the 'sensible' approach to identifying the 'version' of something didn't seem to match up between components. For everything but Rawhide, it's actually pretty easy. We can identify 'composes' with this version scheme: RELEASE [MILESTONE] [COMPOSE] RELEASE is a Fedora release number - '21', '22', '23' etc. MILESTONE is Branched, Alpha, Beta, or Final. COMPOSE is either a date (for a nightly build), or a TC/RC identifier. This works, AFAICS, for all composes except Rawhide, regardless of whether you're talking about a compose, an image, or a release validation event. Some examples: 21 Branched 20140806 18 14 Beta 22 Alpha RC3 13 Beta TC1 For any of those, there could be a compose, some images, and a release validation event, and we can use the same version identifier to talk about all of them, and all the tools can use the same variable names and identifiers and stuff. Great. The tricky case is Rawhide nightlies. When I set up the new nightly compose approach for F22, it seemed to make sense to set up the naming following the above scheme, with a release number and 'Rawhide' as the milestone. So to wikitcms and relval the version of the 'current' event is '22 Rawhide 20150207'. When I built fedfind - the thing that finds *images*, i.e. it doesn't concern itself with validation test events - that didn't actually make any sense at all. If you look at the details of finding Rawhide nightly *images*, there's never a version number. There isn't one in the Mash URL where the boot.isos and packages live. There isn't one in the Koji tasks. So I built fedfind to treat 'Rawhide' as a *release*. To fedfind, the version for the images for the current validation event is something like 'Rawhide 20150207'. Which worked fine for fedfind, but led to dissonance whenever I tried to do something with both wikitcms and fedfind. I sort of mentally fought with this for a while and came up with ways to handle it, but I didn't really have a good mental model of what's going on. This morning though I think I've got a good way to think about it. Here's the thing: Rawhide nightly *composes* - the tree and images - don't have a release number. It's not just that we can ignore it for fedfind's sake, they really don't have one at all. Rawhide is a rolling distribution. The correct way to think of the 'version' of any incarnation of Rawhide that gets frozen in time somehow - an image, a tree - is 'Rawhide DATE'. However, *validation test events* for Rawhide nightly composes *DO* have a Fedora release number. We effectively 'apply' a Fedora release number to the validation test event at the time we create it. Conceptually speaking, when we do that, we are making a declaration: "Given our knowledge of the Fedora release process, we declare that testing the Rawhide nightly images for this date forms a part of release validation testing for this future Fedora release number." When I started thinking about things this way, it started to get a lot clearer. So this morning I've been kinda refactoring things in all the tools - relval, python-wikitcms, fedfind, and my pending patches for openqa_fedora_tools - to follow this conception. I'm going to try and make it so that absolutely any time you talk about a *release validation event*, the RELEASE [MILESTONE] [COMPOSE] pattern applies. RELEASE is mandatory and is always a Fedora release number. MILESTONE is Rawhide, Branched, Alpha, Beta, or Final. COMPOSE is TCn or RCn (where n is a number) for Alpha/Beta/Final, a date in YYYYMMDD format for Rawhide/Branched. When you talk about a *compose*, the same format applies for everything except Rawhide, but for Rawhide nightlies, the version format is: Rawhide YYYYMMDD There are currently bits of relval and python-wikitcms that use different names for what are essentially 'MILESTONE' and 'COMPOSE': Milestone: 'tree', 'build'... Compose: 'date', 'version'... I'm going to basically throw all those out and standardize on the names 'milestone' and 'compose'. Note one significant exception to this - the wiki templates will still have separate 'date' and 'compose', with 'date' set for nightly events but 'compose' set for TC/RC events. This is because wiki template syntax is pretty limited - it's not really capable of reading a single value and deciding whether it looks like a TC/RC identifier or a date. We have to be able to do something like 'if there's a value for date, do (nightly thing), otherwise do (tc/rc thing)'. They're a *bit* strange as names when applied to a branch and a date, but at least it's always consistent and you don't have to remember different terms. Note that python-wikitcms now has two new methods Wiki.get_validation_event() and Wiki.get_validation_page() which will give you a correct ValidationEvent or ValidationPage instance for a given 'release', 'milestone' and 'compose' regardless of whether that's a Rawhide nightly, Branched nightly or TC/RC compose. It also does guessing for *existing* nightly events - you can just give it a release number and a date and it'll return whichever of Branched or Rawhide exists for that date. I'm trying to make the tools as 'frictionless' as possible so you can pretty much always pass the right values with the names 'release, milestone, compose' and things will work. Notably, fedfind.release.get_release() should be 100% compatible with the 'validation event'-style naming. *Even for Rawhide nightlies*, you can do get_release(release=22, milestone='Rawhide', compose='20150212') and it's smart enough to give you a RawhideNightly. But you can *also* do get_release(release='Rawhide', compose='20150212'), or get_release(milestone='Rawhide', compose='20150212'), or simply get_release(date='20150210') and get the right thing. To get Branched, you'd do get_release(release=22, compose='20150212') or get_release(release=22, milestone='Branched', compose='20150212'). You will *usually* be able to parse a fedfind object's 'version' or 'release', 'milestone' and 'compose' properties into the matching release validation event-style version, but you will *not* be able to parse a fedfind object for a Rawhide nightly compose in this way, because as we saw above, Rawhide nightly composes *do not really have a release number*. The 'release' property for fedfind Rawhide nightly objects will always be 'rawhide'. Anyway, hope that explains things for anyone who's interested and I can always use this as a reference later :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
