[Dev] Feathercoin Software Release Status & Information

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.

https://bitcoin.org/en/developer-guide

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 0.9.3.1 : Current Packaged release.
http://forum.feathercoin.com/topic/8162/dev-feathercoin-version-0-9-3-1-official-release-feedback/2
http://forum.feathercoin.com/topic/7271/what-s-new-in-bitcoin-0-9-x-we-ready-upgrade

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 0.8.7.3

Feathercoin-qt Feathercoind version 0.8.7.3 : Current Packaged release for older Linux distributions.
http://forum.feathercoin.com/topic/6468/feathercoin-0-8-6

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

@Lizhi
Feathercoin-qt Feathercoind version 0.9.3.2 - beta test version
http://forum.feathercoin.com/topic/8570/dev-release-candidate-feathercoin-0-9-3-2-check-list
http://forum.feathercoin.com/topic/8519/dev-the-path-to-upgrading-of-blockchain-from-v2-to-v4/2

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

@lizhi
Feathercoin-qt Feathercoind version 0.11.2 - beta test version
http://forum.feathercoin.com/topic/8545/dev-segregated-witness-and-bip-102/2
*
*
*

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
https://github.com/FeatherCoin/Feathercoin

Feathercoin Software Support
http://forum.feathercoin.com/category/18/support

Reporting Software bugs or issues
https://github.com/FeatherCoin/Feathercoin/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

lizhi

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

wrapper

@Lizhi We still need the development procedure list to get 0.9.3.2 / 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.

Notes:
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.

wrapper

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

Version and Feathercoin release Numbering

I thought about re-naming 0.9.3.1 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 0.9.3.2, but I know, that Lizhi is doing work there so I fork the 0.9.3.2 branch to 0.9.3.2-wellenreiter 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.

Wellenreiter

I have created the branch master-0.9 from 0.9.3.1

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

wrapper

This page needs updating to latest release 0.9.6 and proposed 0.9.6.1