Feathercoin daemon and wallet production version 0.18.1
Old daemon and wallet version

[Dev] Feathercoin Software Release Status & Information

  • Moderators | Tip wrapper

    Whilst the Feathercoin releases were initially done by a single person or small team where they followed there own procedure, there are now more people involved.


    Those people involved in developing, testing and releasing the software are open source contributers in their own time which adds further complications, some documentation or notes to other contributers never get done and insisting on strict procedures for hobby work is destructive to progress.

    FTC is currently transitioning to Software Version 0.12 and above. In in order to help @Lizhi and keep track this lists / overview is to help do that. Also help assess the complexity / requirements of future changes.

    This post can be amended by any moderator, or contributer, to aid find the status and general tasks required in the release procedure for the software. To point all the relevant places other documentation is kept, again to aide new contributers.

    Current Development Contributers / admin / contacts :
    @Lizhi @Wellenreiter @Ghostlander @wrapper

    Software Development Status : Feathercoin Blockchain Daemon and Wallet

    Feathercoin-qt Feathercoind version 0.9.6 : Proposed new release

    Feathercoin-qt Feathercoind version : Current Packaged release.

    • Stable release for all “normal” wallet operations
    • Beta test version for Feathercoin “Advanced Features”
    • Include Multi-signature Transactions
    • Major change to move to Bitcoin core code base
    • Backwardly compatible with

    Feathercoin-qt Feathercoind version : Current Packaged release for older Linux distributions.

    • Long term stable release
    • Forward compatible to 0.9.x.x release series
    • Based on Litecoin code base.

    Feathercoin-qt Feathercoind version - beta test version

    • Release to ensure forward compatibility with 0.11
    • Compatibilities : not compatible with version and (?)
    • Release Features?
    • Test requirements?
    • Blockchain compatibility?
    • Possible issues?

    Feathercoin-qt Feathercoind version 0.11.2 - beta test version

    Software development, reporting issues and build instructions

    Github is designated most appropriate to store actual instructions to buils and develop the software and anyone can click there and add an issue. However, that can be a technical process, support on the forum is the first place to try to see if that has been solved already.

    Feathercoin Source Code

    Feathercoin Software Support

    Reporting Software bugs or issues

    Draft Check list - Copy to release thread and customize to release case

    Feathercoin Software Release Procedure check list

    • Github procedure followed
    • Create Release Candidate Post - Completed : @Wrapper
    • Double checks
    • Allocate software status : Test
    • Confirm release candidate auto builds
    • Create test list
    • Double check Test
    • Document and deal with issues : loop
    • Re-designate status
    • Release with documentation / should include any possible problems, or release
    • FTC staff member : sign off release list checked
    • Produce signed binaries
    • Copy package binaries to server
    • Update and check download links work
    • Update Feathercoin forum “Official Release Version” Banner

  • | Tip lizhi

    I push branch. It is a version for upgrading to blockchain v4 and core 0.11.2.

  • Moderators | Tip wrapper

    @Lizhi We still need the development procedure list to get / new versions to “release status” and on to this list.

    This will save time, give you more help and get safer releases with less problems and support issues.

    Currently that is achieved by convincing @Wellenreiter to package up a version he considers to be “tested”. In the future, that would be completion of the check list.

    The check list should include, such as, confirmation of each of FTC specific testing, double checking of the code, a list of the commits / changes & status, a list of benefits, a list of possible problems etc. The list should not be complicated or long.

    This will mean other members and volunteers could perform some of the release specific tasks and not just leave all the work to you and Wellenreiter.

    It will help make sure we don’t miss anything, especially science I know we (Wellenreiter, Wrapper, Aciddude, +) have spent a lot of hours, identifying bugs that stopped the last version compiles on all operating systems.

    I have added a draft check list, you are welcome to modify it or add all the lines I missed.

    The release list should be short and simple, so anyone involved can be noted.
    There can be sub lists of how we handle Github i.e. marking versions as -dev, or specifying the githut release.

  • Moderators | Tip wrapper

    @Wellenreiter mentioned this relevant release procedure information in another thread.

    Version and Feathercoin release Numbering

    I thought about re-naming as master-0.9 as we had it for the 0.8 versions.
    For all future releases the master-x.x is the release version and all numbered versions are the-dev versions.
    Only the master must have the variable _CLIENT_VERSION_IS_RELEASE set to true in configure.ac in the main directory
    All other versions must have the _CLIENT_VERSION_IS_RELEASE set to false

    If a numbered version has all it changes to the master fully tested, I merge the version into the master and further changes must be made on a new branch forked from the master.

    That way we have a more structured approach in version handling.
    If someone wants to develop in parallel of an existing numbered branch, he may fork that branch and add his github name at the end of ‘his’ branch.

    Example: I want to work on, but I know, that Lizhi is doing work there so I fork the branch to and anybody knows exactly what is the base version and who is the main coder there.

    If the patch/development/improvement is done the named branch is merged into the numbered branch which will be tested for bugs and merged into the master branch after testing is done.

    This way we have a more structured aproach in version handling.

  • Moderators | Tip Wellenreiter

    I have created the branch master-0.9 from

    The branches master-0.8 and master-0.9 are now protected, so that no direct push to these branches is possible anymore.

    The package build is linked to master-0.9

  • Moderators | Tip wrapper

    This page needs updating to latest release 0.9.6 and proposed

Log in to reply