Please follow these steps when upgrading a package to a more recent version. This is not to be seen as dogma, but rather as best practice. There are basically two cases we need to consider:
- You do want to keep the version of the bb file that is in OE now (somebody else needs this particular version)
- You don't.
Make sure you add an appropriate entry in checksums.ini and run the file through contrib/source-checker/oe-checksums-sorter.py if the new version fetches new sources.
You do not need to keep the last version of the package
- Use "git-mv packages/$pkg/$file_v1.bb packages/$pkg/$file_v2.bb" so that we don't accumulate unecessary cruft.
- make further changes to packages/$pkg/$file_v2.bb as appropriate.
- At the very minimum do a compilation test "bitbake $file" to make sure the new package does at least fetch and compile.
- inspect the output of "git diff packages/$pkg/". Is this really what you want to commit?
- Final step, publish your work. "git commit packages/$pkg/ && git push". Include conf/checksums.ini in your commit, if appropriate (see above).
You do want to keep the last version of the package
Same as above, except instead of the first step:
cp packages/$pkg/$file_v1.bb packages/$pkg/$file_v2.bb git-add packages/$pkg/$file_v2.bb
Although preventing the accumulation of cruft in the repository is good, you should take into account that distributions may be using a certain recipe and depend upon it. Therefore, before removing a recipe from the repository, do a grep in the 'conf/distro' directory. If the version you are going to remove is being explicitly used, send the respective patch to the development mailing list for 'RFC' first.
- This is too restrictive and I think above paragraph was added to this page without a directive from the core team who should have been the one to decide. preferred-om-2008-versions.inc looks down virtually all recipes. In essence, the above requirement for RFC translates into "all old versions have to accumulate in HEAD or an RFC for their removal sent". I don't think that is what we want. I will certainly not follow that like a slave for packages that I maintain (For example, I will update libassa in a minute to 3.5.0 without keeping 3.4.2 around and wasting my time on re-libtoolizing an obsolete version of a fringe package. Sorry). --Laibsch 22:07, 18 May 2009 (UTC)