TL;DR
· master & develop isnt working
· version1, version2,
branches are in place
· we would like to delete master & develop quickly
· libbitcoin-node is a new repo
· there is a rational roadmap unfolding
A problem we have is that the git flow
<
http://nvie.com/posts/a-successful-git-branching-model> model does not
envision support for down-level releases. It's ideally suited for a web
service, where the product owner only maintains a single "release". This
isn't practical for products that maintain concurrent releases, because
inevitably those releases require independent updates, documentation, etc.
In my experience this is alays a problem with software that "ships" (vs.
that which you build privately and run as a service).
Presently we have a release on obelisk/master and of sx/master. These have
essentially frozen libbitcoin/master as a release, so as not to break these
products. This is why we have hardly pushed anything to master since
creating the develop branches.
Develop is operating as a next version branch. So presently we have
obelisk/develop, libbitcoin/develop, and libbitcoin-blockchain/master (where
there is no develop) working toward a new Obelisk (v2) release. In this case
the branch conventions don't make sense unless we plan to kill obelisk and
sx immediately upon release of v2 (which is not a good idea). As such we
have a problem.
This started to surface yesterday on IRC, as changes in libbitcoin/develop
that are supporting changes to libbitcoin-blockchain started to affect the
pending release of bx/master. bx depends on libbitcoin-client/master which
in turn depends on libbitcoin-protocol/master, as well as
libbitcoin/develop. Because of changes to libbitcoin-develop,
libbitcoin-client and bx were broken. This is because libbitcoin-client
provides backward compat for obelisk/master via API types exposed via
libbitcoin/develop. So we pulled the API types out of libbitcoin/develop and
moved them into libbitcoin-client. Ideally these should exist in an
independent interface repo (like libbitcoin-protocol) but that isolation
didnt previously exist, and libbitcoin-protocol shouldnt take on the
obelisk interface.
As you can see, this can get really bad and without action is going to get
much worse. With parallel development on interdependent products, some with
more than one supported release version, we cannot simply rely on master and
develop. Different components need to take dependencies at different levels
as thngs evolve. Once an API ships it cannot remain in flux. Imagine Boost
continuing to change the API, there would be no versions and it would be
unusable.
So to quickly isolate these issues, allowing work to continue, we have
instituted release branches. The idea is simple, each release for a given
repo on its own branch. What constitutes a released branch (i.e.
quality/stability level) is a matter of documentation for that branch.
Certainly obelisk/master, sx/master and libbitcoin/master are released.
The branch distinction is considered a major version break. Breaking
changes to the API generally fall into this category. This resolves the
issue of supporting downlevel versions with updates and documentation, and
also resolves the ambiguity arising from treating master and develop as two
distinct versions.
However it also implies that master need to go away entirely. I have removed
master and develop from libbitcoin-protocol, libbitcoin-client,
libbitcoin-node and bx. So as not to break any current work, I have not
removed these branches yet in other repos (obelisk, sx, libbitcoin,
libbitcoin-blockchain), but have set the most recent version branch as the
default in all cases. But master and develop should be deleted quickly, so
as to prevent confusion. Also package version numbers have been update to
correlate to the version branches.
The only exception is current work ongoing in libbitcoin/develop. This
branch (only) has unique recent work that was not ported to the release (v2)
branch. Work is underway to complete libbitcoin-node and have obelisk (v2)
take dependency on it, as well as libbitcoin (v2) and then to purge
libbitcoin/develop. In other words we are trying to prevent a v3 branch of
libbitcoin before v2 even ships!
This is everything starting from where we are, to where we will be very
shortly (BX and DarkWallet) and the thinking for libbitcoin-server.
Basically we are in the process of shipping version2 products and starting
on version3, while still supporting version1.
Utility
· libbitcoin/version1
o Boost
o GMP
o Secpk256k1
o LevelDB (conditional)
o OpenSSL (test only)
· libbitcoin/version2
o Boost
o GMP
o Secpk256k1
Obelisk
· obelisk/version1
o libbitcoin/version1
o libconfig++
o Sodium
o ZMQ
o CZMQ
o CZMQPP
SX (spesmilo)
· sx/master (version1)
o libbitcoin/version1
o libwallet/master (version1)
o obelisk/version1
o libconfig++
o ncurses
o python, etc
DarkWallet Obelisk
· libbitcoin-blockchain/version2
o libbitcoin/version2
· libbitcoin-node/version2
o libbitcoin-blockchain/version2
· obelisk/version2 (DarkWallet release)
o libbitcoin-node/version2
o libconfig++
o Sodium
o ZMQ
o CZMQ
o CZMQPP
BX
· libbitcoin-protocol/version2
o libbitcoin/version2
o protobuf
· libbitcoin-client/version2
o libbitcoin-protocol/version2
o Sodium
o ZMQ
o CZMQ
o CZMQPP
· libbitcoin-explorer/version2 (bx)
o libbitcoin-client/version2
Libbitcoin Server (*) & Libbitcoin Node (**)
· libbitcoin-blockchain/version3
o libbitcoin/version2 (or 3 as necessary)
· libbitcoin-node/version3
o libbitcoin-blockchain/version3
· libbitcoin-server/version3
o libbitcoin-blockchain/version3
o libbitcoin-protocol/version2 (or 3 as necessary)
o Sodium
o ZMQ
o CZMQ
o CZMQPP
* libbitcoin-server/version3 may also include layered websockets/JSON
protocol support.
** libbitcoin-node/version3 should be able to install independently
alongside libbitcoin-server/version3.
e
::
[Libbitcoin] git flow, versioning, …
