Using repo to make 'regular' releases

historical

Hi neels,

On Tue, Apr 25, 2017 at 03:40:15PM +0200, Neels Hofmeyr wrote:
> Let me comment as well as recap the things discussed on OsmoDevCon:

thanks.

> 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.

correct.

> The name floating around so far has been "Osmocom-Cellular".
> This makes a name and version scheme of e.g.:

Alternatives:
Osmocom-CellNet
Osmo-CellNet

or something like that.

>   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?

I don't really think there's much confusion.  But OsmoCellNet or
variants of it would be OCN and thus not easily confused?

> 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?)

No, OsmocomBB would not be part of it.  CellNet might improve upon that,
as most people probably would not intuitively consider the phone part of
the network.  An alternative is of course OsmoPLMN... but then, who
knows what that is ;)

> 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?

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.

> 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.

Correct.  Osmocom-Network / OsmoCellNet includes also things like
OsmoBTS and OsmoPCU, as well as any of the current programs of
openbsc.git, osmo-hlr.git, etc.

> 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?

> (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.

> 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"?

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.

> 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.

> 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.

Yes, I think at every time we make a release, we go through the
TODO-RELEASE file and change the libversion accordingly, ...

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)