Release and versions

Release and versions

[Michael Wood]

Hi,

We're currently manually maintaining a file[1] that maps metadata 
release names e.g. 'fido' to the corresponding Bitbake version in 
'toasterconf'. This is time consuming and confusing for people who are 
running Bitbake/Toaster or Poky to work out which toasterconf is suited 
for their setup.

Currently the only real need for these files is to know which Bitbake 
versions are supported with which metadata versions, without someone 
reading https://wiki.yoctoproject.org/wiki/Releases and editing a file 
and submitting it. Would it make sense to make Bitbake versions match 
those of it's metadata?
If departing from the current numbering scheme wouldn't be welcomed, 
would there be room for a compromise where the Bitbake versions also 
contain the release name e.g. 1.26_fido?

Thanks,

Michael

[1] 
http://cgit.openembedded.org/openembedded-core/tree/meta/conf/toasterconf.json

Re: Release and versions

[Richard Purdie]

On Thu, 2015-11-19 at 12:41 +0000, Michael Wood wrote:
> We're currently manually maintaining a file[1] that maps metadata 
> release names e.g. 'fido' to the corresponding Bitbake version in 
> 'toasterconf'. This is time consuming and confusing for people who are 
> running Bitbake/Toaster or Poky to work out which toasterconf is suited 
> for their setup.
> 
> Currently the only real need for these files is to know which Bitbake 
> versions are supported with which metadata versions, without someone 
> reading https://wiki.yoctoproject.org/wiki/Releases and editing a file 
> and submitting it. Would it make sense to make Bitbake versions match 
> those of it's metadata?
> If departing from the current numbering scheme wouldn't be welcomed, 
> would there be room for a compromise where the Bitbake versions also 
> contain the release name e.g. 1.26_fido?

At least in principle, OpenEmbeddedded is one possible metadata
implementation which uses bitbake as its core tool. There is a pretty
strong abstraction of "task execution" from the metadata.

Bitbake isn't tied to the OpenEmbedded release cycles although we do
tend just to release it at those points so there is a stable branch to
use for the release series. We've saved "bitbake 2.0" for some other
time for example compared to Yocto Project 2.0 so the version numbers
are out of sync and always have been. I'm resistant to just making
everything follow each other since whilst they do happen to have the
same maintainer and release cycles at present, it could change in the
future.

Obviously toaster is quite a weird hybrid part since its much more tied
to OpenEmbedded than bitbake itself is, but its also tied to bitbake
too.

I'd also worry about toaster if toaster makes what is an adopted
convention a hard requirement since in product environments, I doubt
mappings will be this simple.

Its not the first time I've heard the request and I do understand the
confusion it causes, equally, I do think people should understand the
different project components do have version numbers and release cycles
and that there are different components.

FWIW I think 1.26_fido is pretty ugly and don't like it at all. The
compromise is probably to create 1.26 and fido branches and just have
them track each other. That pushes the problem from the toaster people
onto me instead. Branches are cheap in git thankfully.

Cheers,

Richard