This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Neels Hofmeyr nhofmeyr at sysmocom.deLet me comment as well as recap the things discussed on OsmoDevCon:
On Mon, Apr 24, 2017 at 01:26:20PM +0200, Harald Welte wrote:
> I don't mind what structure the actual version numbers take.
At OsmoDevCon as one of the very last items, we basically agreed for
year+month style version numbering, and that we should not use just
"Osmocom" for it, since Osmocom is much more than our core network
+ BSC (etc) infrastructure.
The name floating around so far has been "Osmocom-Cellular".
This makes a name and version scheme of e.g.:
Osmocom-Cellular 17.04
Just now I notice that this would actually blur/confuse with the name of
Open Cellular at least when abbreviated. Or maybe that's a good thing?
Also Osmocom-BB is technically also part of "Cellular" but will not be
part of what we plan to wrap in a release. (The plan is not to include
*all* of the osmocom repositories in a release, right?)
It occured to me that "osmo-net" or "osmo-network" or "OsmocomNetwork"
(explicitly without the 'core') could be a good name for releases.
What do you think about that?
For example, we can call the releases:
"osmocom-net-17.04"
"osmocom-net-17.07"
etc.
In a separate discussion, we've also been looking for a name to replace
"openbsc.git", to combine the MSC+BSC+SGSN+MGCPGW realms. The conclusion
of *that* name discussion so far has been that we will instead try to
split up into many smaller repositories: one for the MSC, one for the BSC,
one for the SGSN... Does the Osmocom-Network name fit this? We should not
use the name for both: the release also includes libosmocore, libosmo-*,
osmo-bts, osmo-iuh, osmo-hlr, while the repository would have only been
for MSC+BSC+SGSN+MGCPGW. So I would use the "Network" name for the
release, and I would still go for separation of openbsc.git into smaller
entities.
To be contained in a release, RFC:
libosmocore/
libosmo-abis/
libosmo-netif/
libosmo-sccp/
libsmpp34/
openggsn/
openbsc/ --> split as
osmo-msc/
osmo-sgsn/? osmo-ps/?
osmo-bsc/
osmo-hlr/
osmo-iuh/
osmo-bts/
osmo-pcu/
osmo-trx/
osmo-python-tests/
asn1c/
libasn1c/
sysmo-bts/layer1-api/
octphy-2g-headers/
osmo-gsm-manuals/
(Any additions or removals to this list?)
What if a release turns out to contain a critical bug? The simplest way we
would "resolve" that for now is to tell the users to revert to a release
that works and wait for the next regular release.
Nevertheless, it would be good to have a versioning scheme that allows for
future changes in the release schedule without breaking the naming
conventions. If we would like to tag several releases within a month, we
could append a minor version like "osmocom-net-17.07.2". Should we add a
".0" by default? "osmocom-net-17.04.0"? Should we drop the leading zero
from the month? "osmocom-net-17.4.0"?
My personal choice for release names converges to:
osmocom-net-17.6.0
osmocom-net-17.9.0
osmocom-net-17.12.0
osmocom-net-17.12.1 <-- critical bugfix release ("backed by funding")
osmocom-net-18.3.0
Please comment on the naming -- the time window for permitted bike sheds
is still open now.
I suggest that we follow a regular release schedule of: at the beginning
of March, June, September and December. (so that we don't need to roll a
release during/right after the festive season, i.e. not on 1st January)
More details on releases:
We will so far provide simple tagging of an otherwise arbitrary state of
the master branches -- the aim is merely to provide a common handle to
users to be able to talk about the same "version" of our software, to
allow using the same software state without the need to pass individual
git hashes around. That means:
- we will *not* maintain older releases with backports,
- we will *not* do any special verifications of the working state of
release X beyond the common sensical checks.
- We *will* require a release to pass all stock 'make check' and 'make
distcheck' (as we do for all our patches),
- *and* we will require the osmo-gsm-tester setup to be in production
before commencing releases (I'm on it), so that
- we will require a release to pass the osmo-gsm-tester physical tests.
If anyone is interested in maintenance of older releases or more extensive
release management, you are a) free to do so and/or b) request such,
backed by appropriate funding (for a longer term, probably).
Our releases will be scheduled every three months for the time being.
The individual git repositries will remain separate, and each will have
their own version (maintained in signed git tags to be used for
compatibility checks in autoconf).
The release name should also be tagged in each of the individual git
repositories (without interfering with 'git describe', i.e. non-signed
non-annotated git tags, best prefixed by "release_" or "release/" to allow
looking it up automatically?). The combined release repository (be it by
repos or by git submodules) shall reference those release tags instead of
individual commit hashes (basically to make sure we do have such tags in
place).
Upon invoking 'osmo-foo --version', we would ideally output both the
individual 'git describe' version as well as the larger release version
sort of like
▶ osmo-msc --version
OsmoMSC version 0.15.0.735-1759 (osmocom-net-17.6.0)
What if it's from a bleeding edge master, i.e.
most-recent-release-tag != HEAD?
▶ osmo-msc --version
OsmoMSC version 0.15.0.735-1759 (osmocom-net-17.6.0-dev)
Or maybe rather a scheme combining both? like:
OsmoMSC version 17.6.0-0.15.0.735-1759
Though the library version used for autoconf checks should not contain the
release name -- so I would personally opt to keep these entirely separate,
meaning that we would add a separate variable to the config.h (like
$RELEASE) determined by a separate script.
Loosely related and still open is the question of a scheme to effect
version bumps of the individual projects. I had at some point started to
do a tagged version bump for each API addition to e.g. libosmocore, but
that was a lot of overhead (including adjusting configure.ac of dependent
projects). It was somewhat agreed that we would collect significant API
changes in the TODO_RELEASE text file and bump a version tag whenever a
"new release (TM)" would be made ... but we never defined when we would do
that nor how exactly. So, added bonus would be to resolve this question
along with this discussion, alas it might blow up the bikeshed
permutations... Naive question to clarify: if we have overall release
tags, why exactly do we need individual release numbers for each
subproject -- and then decide on a process to facilitate that need; I'm
blanked out on its use at the moment. It seems to me we could completely
replace individual project versions with the overall release ("17.6.0"),
*if* we accept that non-changing projects would have several versions
tagging exactly the same code state.
The other way would be to bump the individual projects' versions upon each
overall release, iff they have changes (at all? to their API?) since the
last release. This would mean way more release work than just glorifying
a given state of the master branch, but would make a lot of sense in the
logic of a release process. The effort should hopefully be fine to do
every 3 months, only.
Your thoughts are welcome.
Actual example implementations would also be welcome to provide a basis to
work on.
All in all we have agreed on various guidelines/facts but have not
completely got a fix on the process and all the details yet. Please
provide your feedback, and/but let's decide soon.
~N
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170425/697ddf13/attachment.bin>