ZmnSCPxj writes: > Good morning Christopher, > >> Hi ZmnSCPxj, >> >> Sorry for the delay in getting back to you. >> >> guix-patches--- via guix-patches@gnu.org writes: >> >> > In addition to updating, I made as well, separate `bitcoin-core-0.20` >> > and `bitcoin-core-0.21` packages. Due to RPC changes, it is possible >> > that other programs compatible with older `bitcoin-core` version is >> > not compatible with newer version. Thus, an `operating-system` >> > declaration, may need to pin a specific major version. >> >> I think it's OK to keep older versions if that's important, but it would >> be good to specifically note why specific older versions are useful to >> keep. I'm saying that because it's useful to know when an older version >> can be removed. So, for 0.20 are there incompatibilities that you're >> aware of? > > Previously between 0.18.x to 0.19.0.1, the RPC command > `sendrawtransaction` changed its second parameter from a boolean > `allowhighfees` to a numeric `maxfeerate`. Thus, an automated update > from 0.18.x to 0.19.0.1 would have lead to problems in dependent > software that used the older `allowhighfees` parameter. So I think it > is a good policy in general to provide major versions for Bitcoin Core > at least, to avoid such issues in the future. > > Another is that Bitcoin Core itself has a policy of not pushing > updates; the idea is that the user should consciously elect to update > to a newer version, because there may be consensus changes that the > user does not agree with. Using an unanchored `bitcoin-core` would > break this policy and make Guix provide always the latest available. > Of course, it is possible to use inferiors and so on. > > Finally, 0.21.1 is intended to include consensus policy changes on the > activation of the new Taproot feature. Whatever is deployed in 0.21.1 > may or may not be agreed to by the specific user, thus `bitcoin-core` > should ideally not be updated automatically to 0.21.1. > > Bitcoin Core makes an effort to maintain older major versions in order > to allow users to avoid particular changes in later major versions > they do not agree with. Ok, I've found https://bitcoincore.org/en/lifecycle/#schedule now which makes me feel a little better at keeping older versions around, as there are dates from the upstream project which help signal when removing versions from Guix might be good. >> The second thing is, I wouldn't immediately jump to the >> (make-... pattern, and I would instead use package inheritance. See the >> ruby packages for example [1]. >> >> 1: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/ruby.scm#n95 >> >> Package inheritance makes it simpler to make changes to individual >> versions, and avoids the complexity of introducing a procedure. >> >> Does that all make sense? > > Okay, thank you. On this point, are you OK with sending an updated patch? Thanks, Chris