diff options
Diffstat (limited to 'README.md')
| -rw-r--r-- | README.md | 70 |
1 files changed, 36 insertions, 34 deletions
@@ -11,43 +11,41 @@ Branch Policy - New development is done on **master** branch and most new change requests (PRs) should be proposed as changes to master, unless you know they are applicable to a particular release only. -- Major numbers are stepped up every new release of the GENIVI Compliance - Specification. The release schedule is driven by a time plan. -- Meta-ivi use [semantic versioning](http://semver.org/) for minor and patch - numbers. -- The GENIVI Compliance specification is released annually, while meta-ivi is - released bi-annually meaning that we get a gap. We will create 14.x-rocko - branch together with the Compliance Specification 14.0.0 and 14.x-sumo half - way to 15.0.0. -- Somewhere near a new major release of the GENIVI Compliance specification, a - numbered release branch (e.g. 14.x-rocko and 14.x-sumo) is created from - master, and the new branch goes into stabilization/release phase. -- In the middle between the GENIVI Compliance Specification version 14.0 and - 15.0 a numbered branch is created for the 14.x-sumo meta-ivi release. -- After a versioned release, the release branch remains for maintenance and - updates. -- The project maintainer shall ensure that relevant patches are - cherry-picked to every branch where they apply. I.e. patches should be - back-ported *at minimum* to the Support Window versions as defined below. - In general, prefer a linear commit history (rebase and cherry-pick), applying merge commits only where absolutely necessary to sort out a complex merge situation (which we should rarely have). +- The maintainer shall ensure that relevant patches are cherry-picked to + every branch where they apply. I.e. patches should be back-ported *at + minimum* to the Support Window versions, as defined below. +- Meta-ivi uses [semantic versioning](http://semver.org/). +- The release schedule is driven by a time plan. +- The GENIVI Compliance Specification is released annually, while meta-ivi is + released bi-annually. Major numbers follow the compliance specification. + We will create 14.x-rocko branch together with the specification 14.0.0 + and 14.x-sumo half way to 15.0.0. +- Meta-ivi updates regularly to follow Yocto/Poky releases. +- Somewhere near a new major release of the specification, a numbered + release branch (e.g. 14.x-rocko and 14.x-sumo) is created from master, and + the new branch goes into stabilization/release phase. +- In the middle between the specification version 14.0 and 15.0 a numbered + branch is created for the 14.x-sumo meta-ivi release. +- After a versioned release, the release branch remains for maintenance and + updates. Tag Policy ---------- -- Meta-ivi creates tags based on the Compliance Specification version number as - the major version, for example 14.0.0, 14.0.1, 14.1.0 in accordance with - semver. +- Meta-ivi creates tags, in accordance with semver. Major numbers follow + the GENIVI Compliance Specification. Examples: 14.0.0, 14.0.1, 14.1.0 - Releases are created from the respective working branch. -- Meta-ivi creates a Github release based on the version number in accordance - with our version numbering policy. +- GitHub releases are also created. +- When layer upgrades are done, version numbers will be as follows: - The versions used on 14.x-rocko will start at 14.0.0. - The versions used on 14.x-sumo will start on 14.50.0 to keep the major version numbers in sync. - - Note: Updates to the 14.0.0 release would then become 14.0.1 and/or 14.1.0, - which can be released __after__ 14.50.0. -- Meta-ivi creates GENIVI internal tags upon releasing new GENVI versions, for - example P-0.1, P-0.2 and P-1.0. +- Note: Updates to the 14.0.0 release would then become 14.0.1 and/or 14.1.0, + which can be released __after__ 14.50.0. +- Tags of the type P-0.1, P-0.2 etc, are internal tags used for some + prereleases. Support Window (Bugfixes, improvements) --------------------------------------- @@ -87,15 +85,15 @@ file for information on contacting the maintainers of this layer, as well as instructions for submitting patches. Subscribe to the mailing list - [here](https://lists.genivi.org/mailman/listinfo/genivi-meta-ivi). + [here](https://lists.genivi.org/mailman/listinfo/genivi-meta-ivi). [View or Report bugs](https://at.projects.genivi.org/jira/secure/RapidBoard.jspa?rapidView=10&projectKey=BASE). -Read the [wiki](https://at.projects.genivi.org/wiki/display/PROJ/meta-ivi). +Read the [wiki](https://at.projects.genivi.org/wiki/display/PROJ/meta-ivi). For information about the Yocto Project, see the -[Yocto Project website](https://www.yoctoproject.org). +[Yocto Project website](https://www.yoctoproject.org). For information about the Yocto GENIVI Baseline, see the -[Yocto GENIVI Baseline wiki](https://at.projects.genivi.org/wiki/display/PROJ/GENIVI+Baselines). +[Yocto GENIVI Baseline wiki](https://at.projects.genivi.org/wiki/display/PROJ/GENIVI+Baselines). Layer Dependencies ------------------ @@ -113,7 +111,7 @@ URI: git://git.yoctoproject.org/meta-gplv2 > branch: rocko > revision: b3092960655f51febbcb2dba78ca6fdd7091098f -Using the above git sha's and the master meta-ivi branch, +Using the above git SHAs and the master meta-ivi branch, bitbaking pulsar-image is known to work (the pulsar-image build should be aligned with GENIVI 14.0). @@ -128,14 +126,18 @@ than that is not supported any more, and therefore may not build or run. Supported Machines ------------------ -We do smoke test the builds of the three machines that we currently support: +We do smoke test the builds of the three supported machines: -* QEMU (ARMv7) - emulated machine: vexpressa9 * QEMU (IA-32) - emulated machine: qemux86 * QEMU (x86-64) - emulated machine: qemux86-64 * QEMU (ARM64) - emulated machine: qemuarm64 +Adaptation and testing with other hardware BSPs is typically done by other +community projects like the GENIVI Development Platform, and by product +companies. + Please check on our [wiki](https://at.projects.genivi.org/wiki/display/PROJ/meta-ivi) regarding any community supported machines. For example there Renesas provides a public Board Support Package (BSP) available for use with meta-ivi. + |