Feathercoin daemon and wallet production version 0.19.1
Old daemon and wallet version 0.18.3

[Dev] Feathercoin version 0.9.3.1 Official release & Feedback


  • Moderators | Tip Wellenreiter

    @wrapper I simply open the ui files in …/src/qt/forms, modify them and store again.

    Creating a full qt creator project is not needed in my opinion and may create compatibility issues with the configure process.


  • Moderators | Tip wrapper

    Ok, I’ve found out how to do that. The ui files are in a sub directory of Feathercoin/src/qt/forms

    What would you like to do with any changes?

    i.e Do we treat Lizhis’ 0.9.3.2 as the dev version? Or create a dev version I can possibly push something to be tested (or any little issues I have spot from a “check” over the release )

    Example :

    The first UI dialog box is The About Box. The release date is set with a variable YYYY, which I assume should be set at 2016.
    Cross checking that with the release shows 2014 is displayed as the end date.

    I will now scan all files for 2014 and YYYY to see if this issue is else where …


  • Moderators | Tip wrapper

    @Lizhi @Wellenreiter
    re: YYYY It is not a variable but needs to be set for each release.

    Gonna try pushing that fix to my repos on Github

    https://github.com/wrapperband/Feathercoin

    src/qt/forms/aboutdialog.ui
      Showing the top match. Last indexed on 21 Mar.
          <property name="text">
           <string notr="true">Copyright &amp;copy; 2013-YYYY The Feathercoin Core developers</string>
    

    The Version number on the About form is not a variable, I have updated it, but FTC release seems correct, did @Wellenreiter update the release build?

    It doesn’t look like a variable, or does the make release do some stuff I don’t know about?.

    https://github.com/wrapperband/Feathercoin/commit/f0c6f462085db7534470188d86448c0dd4c0e012


  • Moderators | Tip wrapper

    I’ve further tidied up the comment dialogue, and checked the code that it calls.
    commentdialog.ui

    It’s on Github
    https://github.com/wrapperband/Feathercoin/commit/25b924030f8112c30ac2b8ac6882bb132bf73279
    commentdialog.ui

    It needs testing to confirm it all still works by setting a comment
    also - Review how the input error checking works, by inputing other incorrect data.


  • Moderators | Tip wrapper

    @Wellenreiter @Lizhi
    I have tidied up the layout of debugdialog.ui

    It is in the Help Menu SX Tool : It appears to by a sub dialog of the Shapeshift function, to search for shape shifted coins

    I have changed the height to “block height” and re-aligned the buttons as other dialogs.

    It needs testing, searching for shape shift coins.

    https://github.com/wrapperband/Feathercoin/commit/e6e74b08695852dfe0506f2f031df78fee23b8db


  • Moderators | Tip wrapper

    I have Updated the Layout to opennamedialog.ui to be more standard, and the help text. Text needs double checking for clarity.

    The dialog is for input open names.

    https://github.com/wrapperband/Feathercoin/commit/74f262ac15548bf392d462ca06214349044c1fd1

    Testing
    Needs testing to see if I have correctly interpreted the help line.
    Is it 40 Chars in total? or each as I have put
    What happens if you put 50 characters in?


  • Moderators | Tip wrapper

    I have updated the layout of paperwalletdialog.ui removed “Dogecoin” references in the buttons. Move buttons to more standard positions.

    Just tested that myself it is on File menu, print paper wallet. Needs further tweek to close button position.

    https://github.com/wrapperband/Feathercoin/commit/d38d7f9345be22cb772ce58bdad96da9e48f23bc

    Test
    Check you can still print a paper wallet
    Feilds and number of walllet work when input out of spec.


  • Moderators | Tip wrapper

    Updated the Layout to Fixed transaction tab, shiftdialog.ui, returned tabs to main.

    https://github.com/wrapperband/Feathercoin/commit/78055c7579bbfbd3626bab680b2b30693ef22e83

    Requires double check when compiled


  • | Tip lizhi

    Thanks for improving our UI.


  • Moderators | Tip wrapper

    @lizhi @Wellenreiter @ghostlander

    Tidying up my updates to make them easier to include or test.

    I was going to re-clone the Feathercoin code and apply “single” patches for each change. To make them easier to bring in (or not).

    As it is now, release 0.9.3.1 and Lizhi is on developing 0.9.3.2 and 0.11 beta versions.

    Shall I add the patches to Feathercoin 0.9.3.1 as I have done, or do I need to create 0.9.3.1-dev?

    Or doesn’t it matter?


  • | Tip lizhi

    merge into 0.9.3.2


  • Moderators | Tip wrapper

    Re: Feathercoin-qt UI updates : Call for Compile Test

    Any one fancy building my updated version and check for any errors in the UI updates? before I reconfigure them to merge with 0.9.3.X?

    https://github.com/wrapperband/Feathercoin

    Hi @Lizhi I was just making a brew (cup of tea). Wellenreiter needs to “Merge it somewhere”, I’m still very much learning Github.

    I have been thinking that I will fork Feathercoin again to Feathercoin-dev on my computer.

    I will re introduce the "single changes " and then it will be easier to pull those into the latest test version?.

    My changes can be backported to make a step release 0.9.3.1.1 as they don’t contain any changes to the blockchain or protocols.

    0.9.3.2 is a new version, and needs more thought and collaboration to understand / test those changes independently, before merging them (probably into 0.9.4).

    Then we can move on to assessing 0.11 and catch upstream.

    I will need to set up a QEMU virtual box system to be able to compile and test and I think it would be better to keep checking the code for anything else that has been missed from previous FTC, LTC versions when Transferring to Bitcoin Core.

    I can’t do any of that straight away, so any help compiling and testing the changes before I integrate a merge version …


  • Moderators | Tip Wellenreiter

    @wrapper @lizhi
    I agree with Lizhi, merge your gui improvements to 0.9.3.2.

    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.

    What is your opinion? I hope I wasn’t to complicated.


  • Moderators | Tip wrapper

    Cheers Wellenreiter I agree. Version 0.9.3.1 should be set as the release version and should not have further changes. I agree calling that -master would be a good idea.

    0.9.3.2 should be called 0.9.3.2-Dev, to reduce the confusion we are experiencing which version is which.

    @Lizi Last change to configure.ac on 0.9.3.1 changing the version to 0.9.3.2 needs regressing. So versions are consistent if people build the release from source “master/release” version 0.9.3.1.

    @Wellenreiter Are you happy to mix Lizhi’s version 0.9.3.2 changes might be released as soon? Or do they need more testing / discussion?


  • Moderators | Tip wrapper

    I’ve completed the re-base my changes to 0.9.3.2 and have corrected all the Github links, discusion moved to 0.9.8.2 Dev thread.


  • Moderators | Tip wrapper

    @Wellenreiter said:

    @wrapper @lizhi
    I agree with Lizhi, merge your gui improvements to 0.9.3.2.

    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.

    What is your opinion? I hope I wasn’t to complicated.

    @Wellenreiter Thanks, I say keep to the current system and you are running it at the moment so have an idea what’s best. I’ll move the overall comments to our “Release procedure thread”


  • Regular Member | Tip bitboy11

    Where do I download the Setup.exe file for the official wallet?
    And why isn’t there one on the Feathercoin.com homepage?


  • Regular Member | Tip bitboy11

    This post is deleted!

Log in to reply