MIP-0007

From Mochimo Wiki
Revision as of 14:41, 20 May 2021 by Sputnik (talk | contribs) (Created page with "= MIP-0007 - Implement Release procedures = Presented to the Core Contributor Team on May 20, 2021 by user sputnik == Sponsor(s) == The following Core Contri...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

MIP-0007 - Implement Release procedures

Presented to the Core Contributor Team on May 20, 2021 by user sputnik

Sponsor(s)

The following Core Contributors have "sponsored" this MIP.

NOTE: Sponsorship for these purposes means that these Core Contributors have committed to developing the code on behalf of the community if this MIP is adopted. Note: Core Contributor sponsorship is not required for a MIP to be implemented. It just makes things easier on the community.

Problem Definition

When a release of a wallet or any other part of code is done, there might be some debugging information that can be released by mistake, causing issues to the final user.

Solution Summary

Implement a release procesure for each part, so that each time a release is done this procedure is followed so that all debugging information, flags, and other things are removed. It might also need some specific compilation flags, need to implement a zip with a specific program, use another tool and which one, what version and so on.

This will help the developer to create clean releases, that are not prone to some forgotten things. This release procedure file should be added in the repository itself, as it will also help any other dev needing to create a release.

Hard Fork Required ?

No.

Technical Details

Usually, there are always differences between a debugging version and a release, and it is very common that the coder forgets that he has defined several specific things to ease his development, but that are not to be there for the final user. A good example is the V2.4-0 of the Mojo wallet, where one debug fountain has been left in the properties of the program, and that has been released. This caused lots of issue to lots of customers, because this debug fountain was down and hence users got an error message when they tried to create a tag in one situation on 5.

Using this types of procedures helps devs a lot by knowing: now I want to create a release, what do I have to do... oh yes, let's take the release procedure. This procedure can be only 2-3 steps to follow, but it can also be quite long, all depends on the need. Usually this procedure is just a quite small text document that is made when the dev first creates a release. It represent for him a very good reminder of how he did it last time, without having hassles and fears that he forgets something. He will provide all the steps that he has followed to do the release, remove the debugging information, compile in release mode, explains how to select the release mode, tell if he needs to change a debug flag in some .h files before compiling the release, and so on.


Test Results