On Sat, Nov 08, 2014 at 06:53:43PM -0800, Eric Voskuil wrote:
> ...
>
> Creating a release branch is a very simple means of deprecating (vs.
> obsoleting). It still allows everyone who's ready to move on to the
> new
> branch immediately and requires almost no effort to create (and if
> desired maintain) past releases. As such there's really no downside to
> this approach. Notice that bitcoind is managed in this same manner:
> https://github.com/bitcoin
>
> e
>
>
> On 11/07/2014 02:08 PM, Amir Taaki wrote:
> > We could have version branches, the reason I haven't been merging to
> > master is that it takes work and I'm breaking things a lot now.
> > Ideally once we reach the stage of a release, we'll release a bunch
> of
> > sync'ed tarballs for people who want to build.
> > My priority (as upstream developer) is lack of friction for working,
> > more bureaucracy = more overhead and less work.
> > ...

I'm sorry to say I agree with both of you.

Eric: do you want the toolchain to have the same versionN branches for
compatible versions? Then I'd recommend making `version3` the current
about-to-be-released version, and `version4` what's to follow - since we
already have a `v2.0` tagged release of libbitcoin.

IMO having a `version1` branch that has a `v2.0` tag is more confusing
than skipping a version number for some of the tightly-coupled dependent
projects.

Keeping versions in separate branches will only be an improvement if
someone is to maintain these branches. Otherwise, versioned releases can
be pulled from github using tags, and with one less dependency (git).

Not having a `master` branch is also confusing. It's a common name for
"where we're at now", whether with or without breaking changes to
"latest stable release". It's a nice place to test for regressions and
builds on "unsupported" platforms.