Hi,
for the topic of making "releases" I wondered if we want to explore using "repo" to tie the different Osmocom repositories into a single "release". Below is an example "default.xml" that would make up a release. The default.xml would be maintained in a git repository that we could tag, e.g. something like v201704.1 (vYYYYMM.MINOR).
I could envision we have:
* A simple build shell script to build/install everything * A script to update (and tag) the default.xml to make new releases available.
How to use it (if repo is installed):
repo init -u git://git.osmocom.org/osmocom-cellular-manifest repo sync ./build_all.sh --prefix=/opt/cellular
aand on a new release repo sync ./build_all.sh ...
ideas? comments?
holger
default.xml:
<?xml version="1.0" encoding="UTF-8"?> <manifest> <remote fetch="git://git.osmocom.org" review="gerrit.osmocom.org" name="osmocom"/> <default revision="refs/heads/master" remote="osmocom"/> <!-- base libraries --> <project name="libosmocore" revision="9e83c3d5ca64428befe74e5aad61bd84bccaf309"/> <project name="libosmo-abis" revision="bf7976c0b0076410ad1bd67061dd18d0f33a7f43"/> <project name="libosmo-netif" revision="c108c9db969c4d4abaccc88419b4ac0c44957365"/> <project name="libsmpp34" revision="cc0bcd6bc051d5ccaf32cdbbc28f073369900857"/> <project name="libosmo-sccp" revision="57d0449d4ed5d82050c52551c8ad6195db38fdf1"/>
<!-- RAN --> <project name="osmo-trx" revision="de116e90c03c534fa4b51ef40dfd2bb9e843c86e"/> <project name="osmo-bts" revision="25742a5929edecc545a4fc254f678cc834f8c3b3"/> <project name="osmo-pcu" revision="e6d26ec09c2bcd2126416a58cb23af27318ec67e"/> <project name="osmo-iuh" revision="46fea15afc38fb995baf4100f4de1d6a3565899f"/> <project name="openggsn" revision="19e19e3609508d121ba46c165e5ed1502a3cf9da"/> <project name="openbsc" revision="d75f11e6f26a50c11f73625de5c0833971900cde"/> <project name="osmo-sip-connector" revision="417f2542163edfe8ac8729918e2452dc7787a3d7"/>
<!-- Core --> <project name="osmo-hlr" revision="743cf42ac5dfa2661317e73f70b204bde7450ff2"/>
<!-- Misc --> <project name="osmo-gsm-manuals" revision="4b593a2259a107211489940b8b59f44219e73b2d"/>
<!-- Copying a build script to the top level directory --> <project name="osmo-ci" revision="e72f35cfa9969e52d0018ba4661f4519519c39ba"> <linkfile src="build/build.sh" dest="build.sh"/> </project> <project name="python/osmo-python-tests" path="osmo-python-tests" revision="baa6f12260c383f40a477b71743b16940c50e5aa"/> </manifest>
On Sun, Apr 23, 2017 at 01:04:56PM +0200, Holger Freyther wrote:
Hi,
for the topic of making "releases" I wondered if we want to explore using "repo" to tie the different Osmocom repositories into a single "release". Below is an example "default.xml" that would make up a release. The default.xml would be maintained in a git repository that we could tag, e.g. something like v201704.1 (vYYYYMM.MINOR).
I could envision we have:
- A simple build shell script to build/install everything
- A script to update (and tag) the default.xml to make new releases available.
I like the central handle on dependencies, but I don't really like XML. Why not use the git submodules approach? Can't submodules tag specific revisions?
~N
On 23. Apr 2017, at 14:54, Neels Hofmeyr nhofmeyr@sysmocom.de wrote:
I like the central handle on dependencies, but I don't really like XML. Why not use the git submodules approach? Can't submodules tag specific revisions?
I have just seen repo used for Android and the Qualcomm MD9615 (Quectel EC2x) and it seemed to do quite well to clone/checkout/copy and later sync/update it. git submodule will probably work equally well.
holger
Hi,
I like the central handle on dependencies, but I don't really like XML. Why not use the git submodules approach? Can't submodules tag specific revisions?
I have just seen repo used for Android and the Qualcomm MD9615 (Quectel EC2x) and it seemed to do quite well to clone/checkout/copy and later sync/update it. git submodule will probably work equally well.
I like the idea. I think repo is going to work better for this kind of stuff and also given the amount of git repositories we are handling.
I would also use branches/tags inside the repo repository. For instance, branch "master" is mapped to all master branches from all git repositories, then branch "version1" points to specific versions or revisions. This way it can be used both for building/testing development + releases.
It can be great too to use this repo repository to easily switch all git repositories to a given development branch. For instance, if we want to test 3g nowadays, we need to set most git repositories to branch "master, then repository A to branch X, repository B to branch Y, etc. By using repo, you just create a new branch "3G" modifying the xml to point to your git repository specific branch (default=>master, A=>X, B=>Y), and then everybody can easily test it by switching the repo repo to "3g" branch, then calling repo sync + build_all.sh
What about using a Makefile instead of a build_all.sh script? We can ten perhaps paralelize some autoconf building between repositories which have no depndencies to speedup build/test time.
Hi,
I like the idea. I think repo is going to work better for this kind of stuff and also given the amount of git repositories we are handling.
Imho repo is the better choice compared to git submodule, which I so far only used in quite basic no-dependency projects to "bind"one common-ci repo.
I would also use branches/tags inside the repo repository. For instance, branch "master" is mapped to all master branches from all git repositories, then branch "version1" points to specific versions or revisions. This way it can be used both for building/testing development + releases.
I made a spike/hands-on [1] last night to get a better understanding of repo, because I so far only consumed/used it. The created "repo" clones all necessary repositories for the accelerate3g5 CN stack, but the default.xml manifest already holds all Osmocom-CellNet repositories mentioned in this thread. So one can already switch between "default" and "accelerate3g5" project as well as add new projects.
My understanding is that we need branches/tags to use repo for several Osmocom-CellNet projects (not optional). That's why I created "accelerate3g5" branch where release (candidate) tags of actual git repositories can be tested and tagged as release (candidate) within the "accelerate3g5" repo branch. The tested/verified state within the accelerate3g5 branch will be then merged to the master and tagged as a release to detach its state from HEAD.
...and then everybody can easily test it by switching the repo repo to "3g" branch, then calling repo sync + build_all.sh
Inspired by your post I added a script to build the accelerate3g5 CN stack to the repo repository, so one can build the entire stack with 3 lines:
$ repo init -u https://github.com/blobbsen/repo-handson -m accelerate3g5.xml $ repo sync $ .repo/manifests/build_accelerate3g5.sh
Note: should work on FreeBSD too (gmake/make topic)
Probably worth discussing is the topic whether mentioned build script should live in the repo repository or in osmo-ci (if we agree to add osmo-ci)?
Although, osmo-ci sounds like a good place I like the fact one can put those build scripts also in the repo repository itself. Perhaps an osmo-repo helper script, which holds some handy shortcuts à la switchToProject, switchToBranch, because to switch branches or project one basically uses the three above mentioned lines again (cumbersome).
What about using a Makefile instead of a build_all.sh script? We can ten perhaps paralelize some autoconf building between repositories which have no depndencies to speedup build/test time.
Interesting idea! :)
What do you think about [1] in general?
Cheers, André
Hi Holger,
On Sun, Apr 23, 2017 at 01:04:56PM +0200, Holger Freyther wrote:
for the topic of making "releases" I wondered if we want to explore using "repo" to tie the different Osmocom repositories into a single "release". Below is an example "default.xml" that would make up a release. The default.xml would be maintained in a git repository that we could tag, e.g. something like v201704.1 (vYYYYMM.MINOR).
I would still suggest that the "release" tags should also be made in all the individual repositories. Otherwise, while looking at git history in an individual repository during development/review, it is not obvious which patches are in which release or not.
So having the specific 'git commit' IDs into repo and bypassing release tags inside the individual git repositories, you are taking this information out of the individual repositories. I don't generally think that's a good idea.
So if at all, I believe 'repo' should refer to tags inside the inidvidual repositories [not sure at possible], or the repository-individual tags should be auto-generated in the same process when generating a new xml file in repo.
On 23. Apr 2017, at 15:02, Harald Welte laforge@gnumonks.org wrote:
Hi Holger,
I would still suggest that the "release" tags should also be made in all the individual repositories. Otherwise, while looking at git history in an individual repository during development/review, it is not obvious which patches are in which release or not.
I would like to be lazy but if the have pending SO_VERSION bumps we need to make a proper release (bump the version, update the debian package). Maybe to make it a bit more easy drop a version scheme like v1.2.3 and have a strictly monotonic increasing number like used for systemd/udev (and then still have v123.X for minor releases) or the date approach I mentioned before.
So if at all, I believe 'repo' should refer to tags inside the inidvidual repositories [not sure at possible], or the repository-individual tags should be auto-generated in the same process when generating a new xml file in repo.
If we go for date as version number we should be able to automate most of it and assist where manual work is needed (e.g. work on the TODO-RELEASE).
holger
Hi Holger,
On Mon, Apr 24, 2017 at 11:45:34AM +0200, Holger Freyther wrote:
I would still suggest that the "release" tags should also be made in all the individual repositories. Otherwise, while looking at git history in an individual repository during development/review, it is not obvious which patches are in which release or not.
I would like to be lazy but if the have pending SO_VERSION bumps we need to make a proper release (bump the version, update the debian package). Maybe to make it a bit more easy drop a version scheme like v1.2.3 and have a strictly monotonic increasing number like used for systemd/udev (and then still have v123.X for minor releases) or the date approach I mentioned before.
I don't mind what structure the actual version numbers take.
So if at all, I believe 'repo' should refer to tags inside the inidvidual repositories [not sure at possible], or the repository-individual tags should be auto-generated in the same process when generating a new xml file in repo.
If we go for date as version number we should be able to automate most of it and assist where manual work is needed (e.g. work on the TODO-RELEASE).
As indicated, the important part for me is to have tags in the individual repositories, and then use those tagged versions in the repo manifest. Beyond that, I'm open to whatever you guys think makes sense.
Let 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
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
Hi,
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
I agree with Harald, adding the "net" part makes sense if we want to keep osmocombb out of it, "cellnet" sounds good. Not sure if adding a reference to "Infrastructure" could also make sense, such as "Osmo-CellInfra" or "Osmo-CellInfraNet".
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.
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.
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.
I have to say I'm not particularly against this idea from Neels. It would simplify a lot naming of the versions of all projects.
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
On 26.04.2017 10:07, Pau Espin Pedrol wrote:
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.
I have to say I'm not particularly against this idea from Neels. It would simplify a lot naming of the versions of all projects.
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
Hi Neels,
On Wed, Apr 26, 2017 at 04:07:15PM +0200, Neels Hofmeyr wrote:
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":
actually, it's mostly the dashed version for the executables, and then the git repo follows that.
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.
I also like the shorter names. However, we already have the Osmocom trademark in US and EU, and it might make sense to reflect that in naming, should the need ever arise to defend against a copycat or some other misrepresentation of the project and/or its software.
Personally I would be fine with either one:
osmo-cell-net / OsmoCellNet
or
osmocom-cell-net / OsmocomCellNet
my vote goes for the latter, due to above reasoning.
-
André Boddenberg -
Harald Welte -
Holger Freyther -
Max -
Neels Hofmeyr -
Pau Espin Pedrol