Forum Home
    • Register
    • Login
    • Search
    • Recent
    • Tags
    • Popular

    [Dev] Feathercoin version 0.9.3.1 Official release & Feedback

    Technical Development
    feathercoin release
    7
    40
    35724
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • wrapper
      wrapper Moderators last edited by 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.

      1 Reply Last reply Reply Quote 0
      • wrapper
        wrapper Moderators last edited by 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

        1 Reply Last reply Reply Quote 1
        • wrapper
          wrapper Moderators last edited by 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?

          1 Reply Last reply Reply Quote 0
          • wrapper
            wrapper Moderators last edited by 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.

            1 Reply Last reply Reply Quote 0
            • wrapper
              wrapper Moderators last edited by 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

              1 Reply Last reply Reply Quote 0
              • lizhi
                lizhi last edited by

                Thanks for improving our UI.

                wrapper 1 Reply Last reply Reply Quote 0
                • wrapper
                  wrapper Moderators @lizhi last edited by

                  @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?

                  1 Reply Last reply Reply Quote 0
                  • lizhi
                    lizhi last edited by

                    merge into 0.9.3.2

                    1 Reply Last reply Reply Quote 0
                    • wrapper
                      wrapper Moderators last edited by

                      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 …

                      1 Reply Last reply Reply Quote 0
                      • Wellenreiter
                        Wellenreiter Moderators last edited by

                        @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.

                        Feathercoin development donation address: 6p8u3wtct7uxRGmvWr2xvPxqRzbpbcd82A
                        Openpgp key: 0x385C34E77F0D74D7 (at keyserver.ubuntu.com)/fingerprint: C7B4 E9EA 17E1 3D12 07AB 1FDB 385C 34E7 7F0D 74D7

                        wrapper 1 Reply Last reply Reply Quote 1
                        • wrapper
                          wrapper Moderators last edited by

                          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?

                          1 Reply Last reply Reply Quote 0
                          • wrapper
                            wrapper Moderators last edited by

                            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.

                            1 Reply Last reply Reply Quote 0
                            • wrapper
                              wrapper Moderators @Wellenreiter last edited by

                              @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”

                              1 Reply Last reply Reply Quote 0
                              • B
                                bitboy11 Regular Member last edited by

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

                                1 Reply Last reply Reply Quote 0
                                • B
                                  bitboy11 Regular Member @AmDD last edited by

                                  This post is deleted!
                                  1 Reply Last reply Reply Quote 0
                                  • First post
                                    Last post