[Dev] Feathercoin version 0.9.3.1 Official release & Feedback

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!