Looks like the opinions are converging quickly, very good.
It's almost time to cast this into the release wiki page.
On Tue, Apr 25, 2017 at 11:34:45PM +0200, Harald Welte wrote:
Osmocom-CellNet
Osmo-CellNet
It occured to me that "osmo-net" or
"osmo-network" or "OsmocomNetwork"
there are many types of network, and i think anything that narrows it
further down to terrestrial cellular networks, possibly even hinting at
3GPP standards, would be useful IMHO.
+1 for CellNet
with bike shed on word separation:
Let's avoid mixed dash plus camel case.
OsmocomCellNet
osmocom-cell-net
We tend to use the CamelCase in manuals and for project names, and the dashed
version for git repositories. We also tend to use only "Osmo":
OsmoCellNet
osmo-cell-net
I like shorter names (as long as they are still concise). OTOH it could make
sense to mark the overall release with the full "Osmocom" instead, because
it's
not just a specific program.
Personally I would be fine with either one:
osmo-cell-net / OsmoCellNet
or
osmocom-cell-net / OsmocomCellNet
{
naming so far:
git repos / osmo-gsm-manuals / redmine project name
libosmocore / libosmocore / libosmocore
openbsc / OsmoNITB / OsmoNITB
openbsc / OsmoSGSN / OsmoSGSN
osmo-hlr / OsmoHLR / OsmoHLR
osmo-gsm-tester / OsmoGSMTester / OsmoGSMTester
openbsc will soon become:
osmo-msc / OsmoMSC / OsmoMSC
osmo-ps (?) / OsmoSGSN / OsmoSGSN
...
}
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/
not sure if you need the asn1c as part of the release, given that the
asn1c-generated code could be part of it, too?
That's right. For completeness sake we could include it, but we don't really
expect changes to the asn.1. If the need arises, we can always add asn1c later.
libasn1c though will be in the release (for 3G using osmo-iuh).
(Any additions
or removals to this list?)
Not that I know of right now, but I guess we'll find
out as we go ahead.
ack.
I would keep the '0', simply because it seems
more common in year.month
based schemes like that of ubuntu. It's 16.04 and not 16.4.
ok, fine with me.
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)
Sounds good.
- 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.
ACK.
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).
ACK.
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
ACK.
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.
yes, makes most sense. PACKAGE_RELEASE along with the existing
PACKAGE_VERSION
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.
So far I really don't like that idea. It just feels wrong, somehow. I
cannot really explain it.
So far I notice that it feels wrong because it doesn't really match the
semantics 1:1; now Max has found clear terms for the feeling:
I think it's really bad idea to have different
versions pointing to the same commit:
* it's extra headache for testing - we either have to figure out
"duplicate" versions
to avoid useless work or do meaningless testing
* if while making point fix we forget about this duplicity we might end-up with
17.04.1 and 17.06.1 diverged while 17.04 and 17.06 were the same thing for particular
component
* it makes it impossible to mark any component-specific changes between global releases
An intermediate version tag of a subproject would interfere with the
OsmoCellNet release numbers also used in other subprojects as well as the
overall release, a minefield for various confusions.
The other way
would be to [...]
every time we make a release, we go through the
TODO-RELEASE file and change the libversion accordingly, ...
+1
pespin wrote:
As it may be difficult or tedious to sync/fetch the
changes from different
project repositories, we could have a wiki page with a list of new added
features for each release, and when new stuff is pushed into a given project
they could add an entry in the changelist for that project for the next
release.
I think we should stay with the TODO-RELEASE files in each subproject -- it is
in the same place where the changes get committed and allows including these in
feature branches. We need to bump individual project versions anyway for a
release, so we need to look at each individual TODO-RELEASE file anyway. We
could/should even scriptify the release process as much as possible, e.g. from
the osmo-cell-net overall repository, which could fetch the separate
TODO-RELEASE contents automatically.
~N