I looked at it but it doesn’t resolve the core problem. It’s not that we have a problem in referencing one repo from another. It’s relatively straightforward to document/automate the location in the external library at which to depend. The problem is that we need to be able to maintain stable, named, concurrent branches in order to support downlevel releases. A branch is ideally suited to this purpose.



e



From: Lucas Betschart [mailto:lucasbetschart@gmail.com]
Sent: Friday, November 07, 2014 12:36 AM
To: Eric Voskuil
Cc: libbitcoin@???
Subject: Re: [Libbitcoin] git flow, versioning, roadmap details



Makes sense :)



What about using git-submodules



2014-11-06 23:34 GMT-05:00 Eric Voskuil <eric@???>:

TL;DR

·         master & develop isn’t 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 didn’t previously exist, and libbitcoin-protocol shouldn’t 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 mailing list
Libbitcoin@???
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/libbitcoin