On Mon, Mar 24, 2014 at 10:50 PM, Antti Kantee <[email protected]> wrote: > On 24/03/14 17:29, Justin Cormack wrote: >> Rolling releases are generally called releases, while snapshots are >> just stuff you push out. The main thing from the packaging point of >> view though is that (certainly have had issues with rpm in the past) >> is the numbering scheme, snapshots are usually rumpkernel-20140314-1 >> while a release will be rumpkernel-0.1.2-1 and if you change from >> using one to the other it causes havoc as 20140314 is much larger than >> 0.1.2 so you can't upgrade to 0.1.2. Given that x.y.z semantic >> versioning (with ABI changes signified by incrementing the big number, >> except before 1.0) is standard, we should use that, and change as >> soon as possible before anyone starts using the packages, which was >> why I wanted to get that sorted out now.... > > I think an ABI specifier falls into the category of "nice idea, but in > reality wishful thinking". For one, we'll have to bump the major number > every time the NetBSD kernel version is changed (and that's quite > often). Second, it's not uncommon for kernel ABI changes in NetBSD to > accidentally go unnoticed. Third, we're not just limited to the kernel, > but changes with rump kernels too (e.g. the remote syscall protocol, > hypercalls, ...). We'd end up bumping the major with every release, and > that's what a date-based specifier does in addition to conveying useful > information; e.g. 20140314 will not contain NetBSD driver changes > _after_ 20140314. > > Short of lending itself to "release branches" (which I also see as > wishful thinking), I don't see a benefit in a [12...] numbering scheme, > and therefore I vote to preserve the current one.
Well the formalish definition is by API not ABI http://semver.org/ I think the release changes should be by rumpkernel API versioning not netbsd versioning.So if there is a new hypercall revsiion we bump the major number. Can start at 17 if you like... Date based releases give no information about actual rump kernel changes. You could support hypercall revisions with different kernel sources, should there be a requirement to do that, which a date based revision cannot support. Justin ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech _______________________________________________ rumpkernel-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rumpkernel-users
