Dear Osmocom community,
since the NITB-split has completed, and we have integrated 3G fully into master, and also merged nitb-split and nitb packages in one feed, the next step on the agenda was to create packages/feeds that are more stable than "nightly".
After a long day of "release engineering" work and related fixes, starting from today, Osmocom not only has the "osmocom:nightly" feed tracking the "master of the day" of all repositories.
We now also have a "osmocom:latest" feed for various Debian and Ubuntu GNU/Linux distributions which contains packages for the last tagged version of each source code repository.
The setup is fairly similar to that of the "osmocom:nightly" packages and is described at https://osmocom.org/projects/cellular-infrastructure/wiki/Latest_Builds
I've also removed all known references to Nightly_Builds on the wiki and replaced it with a reference to the new Binary_Packages page explaining the differences between Nightly_Builds and Latest_Builds: https://osmocom.org/projects/cellular-infrastructure/wiki/Binary_Packages
As you can see at https://build.opensuse.org/project/monitor/network:osmocom:latest almost all the packages are building already. I intend to fix the remaining three (osmo-bsc, osmo-msc and osmo-pcu) shortly.
On Sun, Oct 29, 2017 at 12:00:59AM +0200, Harald Welte wrote:
After a long day of "release engineering" work and related fixes, starting from today, Osmocom not only has the "osmocom:nightly" feed tracking the "master of the day" of all repositories.
Yay, excellent!
So we can make those three-monthly release feeds we're planning to start in december by essentially pinning the versions of a 'latest' build. (They won't really be "stable" releases, just pinned ones.)
We could theoretically also just copy the 'latest' binaries on a given day to a different download folder without maintaining OBS builds ... but probably better to do actual builds instead for easier "backport" releasing if needed.
We'll probably do a release tagging round in all repositories for each such cycle, 4 times a year, and are free to do more release tags in-between to make 'latest' benefit from fixes or features.
~N
Hi Neels,
On Mon, Oct 30, 2017 at 06:39:26PM +0100, Neels Hofmeyr wrote:
Yay, excellent!
thanks!
So we can make those three-monthly release feeds we're planning to start in december by essentially pinning the versions of a 'latest' build. (They won't really be "stable" releases, just pinned ones.)
ACK.
We could theoretically also just copy the 'latest' binaries on a given day to a different download folder without maintaining OBS builds ... but probably better to do actual builds instead for easier "backport" releasing if needed.
we should have "network:osmocom:release-xyz" feeds for each of the releases we create.
We'll probably do a release tagging round in all repositories for each such cycle, 4 times a year, and are free to do more release tags in-between to make 'latest' benefit from fixes or features.
I'm wondering if it wouldn't make more sense to have git branches (as opposed to tags) for those "overall project releases". This way we could actually - if needed - add fixes or other backports to the respective release branch in the repository, and the OBS builds for that release would simply follow those branches?
On Mon, Oct 30, 2017 at 09:28:06PM +0100, Harald Welte wrote:
I'm wondering if it wouldn't make more sense to have git branches (as opposed to tags) for those "overall project releases". This way we could actually - if needed - add fixes or other backports to the respective release branch in the repository, and the OBS builds for that release would simply follow those branches?
Until we backport something, a tag would suffice, but indeed, using branches could simplify (skip the need for) updating the git target for "network:osmocom:release-xyz" feeds.
~N
-
Harald Welte -
Harald Welte -
Neels Hofmeyr