[Dev] Feathercoin version 0.9.3.1 Official release & Feedback

wrapper

I found this so I’m going to try creating a Qt Creator project from scratch and importing Feathercoin.

https://bitcointalk.org/index.php?topic=1062488.0;wap

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.

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 …

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

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.

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

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?

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.

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

lizhi

Thanks for improving our UI.

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?

lizhi

merge into 0.9.3.2

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 …

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.

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?

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.

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”

bitboy11

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

bitboy11

This post is deleted!