versioning scheme and release tagging for limesuite about limesuite HOT 10 CLOSED

This gets my vote 👍
I'd suggest the sooner we can put this in place, the better.
@ztamosevicius and @rjonaitis, thoughts?

from limesuite.

Sure, this kind of model was used at first just in reverse, the master branch had stable versions, and development has been going on separate branch.

However, I would also like to consider how fixes are handled using a similar scheme of "year.month.patch". Perhaps a release is made, lets say its named 2016.05.0. After some bug fixes, a new release is tagged 2016.05.1

Basically the current scheme is similar, it just uses incrementing build counter, instead of reseting patch counter every month.

from limesuite.

Sure, this kind of model was used at first just in reverse, the master branch had stable versions, and development has been going on separate branch.

Basically its all similar. I think we should continue with feature development on branches that get merged into master -- just as we do now.

The difference with "stable" branch vs what we do now is that 1) release tags come from stable, and 2) anything that is a fix gets applied to stable and "stable" branch is merged into master.

Currently I have been applying fixes and new features to master. I think this is fine for now while we are in heavy development and re-factoring. But soon we need to maintain a stable or release series with patches only -- no breaking changes to API, ABI, features, etc.

Basically the current scheme is similar, it just uses incrementing build counter, instead of reseting patch counter every month.

Here is one way to handle it: In CMakeLists.txt we call set(VERSION 2016.05.0) and use ${VERSION} to setup the sources like the info dialog and perhaps an API call to query the current version.

Eventually, master will become set(VERSION 2016.06.0). But there might be a "stable" branch that is still set(VERSION 2016.05.0). As we apply fixes to stable, the version will become set(VERSION 2016.05.1) on the next release tag. When we build from a non-release tag, the version can become 2016.05.1.commitNo where the last digit is the number of commits since the last tag extracted from git-describe.

from limesuite.

Update: unmerged version_info branch: https://github.com/myriadrf/LimeSuite/tree/version_info

• cmake extracts git hash and version.h info to set library so and version
• Added VersionInfo api calls to query the version string
• Using version string api in dialog about as well
• Improved LimeUtil to print version info and to instantiate connections

from limesuite.

@guruofquality @rjonaitis, do you think we could move to using tagging now? It's going to make things a lot easier when we very soon have a great deal more LimeSDR boards out there, if we can have tagged releases which have been tested and easily refer to these, should someone experience issues and need to try using a previous release etc.

from limesuite.

Ive have been wanting a "stable" branch for the purpose of building binaries from. Sounds like a good idea. To recap:

• making a stable branch that will get only fixes
  • religiously merge stable into master whenever fixes are applied
• keep master compiling, but new features and API changes go into master
• We can have a stable branch and a first tag of the current HEAD as "16.12.0"
  • subsequent tags will be "16.12.1", 2, 3, etc
• master will continue to be "16.12.*" (whatever stable is) until we break/change/add to API
  • if we add an API in feb 2017, it can be "17.02.0" for example
• periodically, master becomes the new stable branch for new release series

All in agreement? and I will go forward and make some tags, branches, and new release uploads... Thanks!

from limesuite.

Gets my vote, @guruofquality.

from limesuite.

@guruofquality Sure, we can go with this scheme

from limesuite.

I made a stable branch, but I didnt merge it into master or tag it yet: https://github.com/myriadrf/LimeSuite/tree/stable

I ended up removing version.h and hard coding some version numbers into the top level cmakelists: https://github.com/myriadrf/LimeSuite/blob/stable/CMakeLists.txt#L22

There is still a timestamp and other stuff built into the library. It can be see with LimeUtil --info. Hopefully this change is ok. Its a matter of updating some numbers in the build when we want to make changes that affect releases.

from limesuite.

Made the first tag: https://github.com/myriadrf/LimeSuite/tree/v16.12.0
Uploading new package based from this release.
Mind the Changelog and the fixes in stable branch. Closing.

from limesuite.