[oe] BBVERSIONS

[Chris Larson]

Greetings all,

I'm emailing about a prototype I threw together of a BBVERSIONS
implementation in BitBake.  This functionality is similar to BBCLASSEXTEND,
but it lists versions, and sets PV rather than doing an inherit.  This
allows you to create one recipe that can build multiple versions of
something.  Either you can do one recipe that can build everything, or you
could (I prefer this) create one recipe for each range of versions which are
built in a given way with a given set of patches.

It helps if you think about an upstream change (which, say, breaks
application of a patch) as being a change going forward.  No one makes a
change assuming it'll be reverted the next release, so it's likely that a
given patch will apply through a set of versions, until another change
breaks it further.  So, metadata and patches is really rarely bound to just
one version, but is instead bound to the series of versions which can be
built in that way and which can have those patches applied.

The version from BBVERSIONS is added to OVERRIDES, to allow for version
specific metadata.  In addition, you can specify a name for the range of
versions, which is also added to OVERRIDES.  As an example, I created a
nano_1.0.0+.bb recipe which builds 1.0.0 through 1.0.6, its BBVERSIONS is
set to 1.0.[0-6].  The BPV variable gets set with the 1.0.0+ value, so it
can be used in the filespath, so the generic files go there, and individual
versions can override further if necessary.

I've been experimenting with a set of files and recipes to build every
version of nano that exists, from 1.0.0 through 2.2.3, with one recipe for
each set of versions.  I'm still investigating to find the optimal workflow
with this, someone else may want just one recipe for all versions, or they
may want to leave it as is, just one recipe per version, but I suspect this
may reduce the number of files duplicated across filespaths amongst versions
which could be grouped together into a single recipe.

Thoughts? Questions? Concerns?  I've been wondering if this is really
worthwhile, but I think it is.  I think there is value in keeping old
versions around, but this allows us to avoid cluttering up the repository as
much, and makes it so that one change to a recipe can affect all the
versions in that range by default, or all versions, rather than just the one
version you tested.  Of course, ideally you'd test all versions, but that's
the case today too, its just that now our recipes get bitrotted instead.
 Personally, I'd rather see the old version content continue to be brought
forward by default, and if it fails to build with that, we fix it, but it's
easier to fix a build than to unclutter the repository.

I'm hoping to get some input on this :)

The bitbake changes: http://github.com/kergoth/BitBake/commits/bbversions
The repository with my experimentations with nano (haven't pushed since I
split the recipe by version range yet): http://gist.github.com/338382
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics