Using repo to make 'regular' releases

historical

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

-------------- 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/20170426/50850362/attachment.bin>