Below is the procedure that is followed during the release process in MOSIP.

• Once an agreement has been reached between the Maintainer and the Community regarding a release, a release branch will be created.

• The branch will be named release-<version> and will be used to transition all dependent projects and the main project.

• The version numbers in the relevant build files will be updated accordingly.

• Following this, the release artifacts will be generated from the designated branch and transferred to the Quality Assurance (QA) team.

• Thorough release testing will be conducted under the supervision of the QA team.

• Bugs that are identified will be assessed by the community, QA team, and product owners.

• All necessary fixes will be made within the release branch.

• Once testing is completed, the QA team must provide their approval for the release.

• The fixes implemented will then be transferred from the release branch to the develop branch.

• A discussion with stakeholders will be initiated to determine whether to proceed with the release or not.

• The final documentation, including Release Notes and a Test Report, will be updated accordingly.

• Upon receiving clearance from the Go/No Go decision, the repositories will be tagged, and the artifacts will be released to NPM, Maven, Testflight, and other relevant platforms.

• The tagged code and artifacts will be deployed on Collab for sanity testing and automation.

• Once the sanity testing is successful, the release will be announced on the Community channels.

Contribution Guide to MOSIP

About

This document provides a set of best practices for MOSIP open source contributions - bug reports, code submissions/pull requests, etc.

For the most part, these guidelines apply equally to any repository regardless of programming language or topic. Where applicable, we outline where individual projects/languages may have additional requirements.

Sources

This document is derived from https://www.contribution-guide.org/

It's expected that over time we will incorporate additional material from our experience and other large projects. We'll update with a list here when that happens.

Version control branching

To know more, read MOSIP Branching Strategy.

Submitting bugs

Due diligence

Before submitting a bug, please do the following:

• Perform basic troubleshooting steps:

  • Make sure you're on the latest version. If you're not on the most recent version, your problem may have been solved already! Upgrading is always the best first step.

  • Try older versions. If you're already on the latest release, try rolling back a few minor versions (e.g. if on 1.2.0.2, try 1.2.0.1 or 1.2.0) and see if the problem goes away. This will help the devs narrow down when the problem first arose in the commit log.

  • Try switching up dependency versions. If the software in question has dependencies (other libraries, etc) try upgrading/downgrading those as well.

• Search the project's bug/issue tracker to make sure it's not a known issue

• If you don't find a pre-existing issue, consider checking with community, in case the problem is non-bug-related.

What to put in your bug report

Make sure your report gets the attention it deserves: bug reports with missing information may be ignored or punted back to you, delaying a fix. The below constitutes a bare minimum; more info is almost always better:

• What operating system are you on? Windows? version, Mac OS X? (10.7.4? 10.9.0?) Linux? (Which distro & version? ), Java (distro & version) Again, more detail is better.

• Which version or versions of the software are you using? Ideally, you followed the advice above and have ruled out (or verified that the problem exists in) a few different versions.

• How can the developer understand what's happening on your end? Logs of the service where the problem occurs. In case it has dependant services please feel free to attach the log of those services as well.

• How can the developers recreate the bug on their end? If possible, include a copy of your code, the command you used to invoke it, and the full output of your run (if applicable.)

  • A common tactic is to pare down your code until a simple (but still bug-causing) "base case" remains. Not only can this help you identify problems which aren't real bugs, but it means the developer can get to fixing the bug faster.

Contributing changes

Licensing of contributed material

Keep in mind as you contribute, that code, docs and other material submitted to open source projects are usually considered licensed under the same terms as the rest of the work.

• Anything submitted to Mosip falls under the licensing terms in the repository's top-level LICENSE file.

  • For example, if a project's/repositories LICENSE is MIT-based, contributors should be comfortable with their work potentially being distributed in binary form without the original source code.

• Per-file copyright/license headers are typically extraneous and undesirable. Please don't add your own copyright headers to new files unless the project's license actually requires them!

  • Not least because even a new file created by one individual (who often feels compelled to put their personal copyright notice at the top) will inherently end up contributed to by dozens of others over time, making a per-file header outdated/misleading.

Version control branching

• Always fork for your work, no matter how small. This allows you to work independently work without impacting other work.

• Always make a new branch for your work, no matter how small. This makes it easy for others to take just that one set of changes from your repository, in case you have multiple unrelated changes floating around.

  • A corollary: don't submit unrelated changes in the same branch/pull request! The maintainer shouldn't have to reject your awesome bugfix because the feature you put in with it needs more review.

• Base your new branch off of the appropriate branch:

  • Bug fixes should be based on the branch named after the oldest supported release line the bug affects.

    • E.g. if a feature was introduced in 1.2.0, the latest release line is 1.2.0.1, and a bug is found in that feature - make your branch based on 1.2.0.1. The maintainer will then forward-port it to 1.2.0.2 and master.

    • Bug fixes requiring large changes to the code or changes to the commons repository which has a chance of being otherwise disruptive may need to base on develop instead. This is a judgement call -- ask the devs over the https://community.mosip.io!

  • New features should branch off of the 'develop' branch.

    • Note that depending on how long it takes for the dev team to merge your patch, the copy of master you worked off of may get out of date! If you find yourself 'bumping' a pull request that's been sidelined for a while, make sure you rebase or merge to the latest master to ensure a speedier resolution.

Code formatting

• Follow the style you see used in the primary repository! Consistency with the rest of the project always trumps other considerations. It doesn't matter if you have your own style or if the rest of the code breaks with the greater community - just follow along.

• Java projects usually follow the https://google.github.io/styleguide/javaguide.html_> guidelines (though many have minor deviations depending on the lead maintainers' preferences.)

Documentation isn't optional

It's not! Patches without documentation will be returned to the sender. By "Documentation" we mean:

• Swagger (for Java; or API-doc-friendly comments for other languages) must be created or updated for public API functions/methods/etc. (This step is optional for some bugfixes.)

  • Don't forget to verify the swagger URL for your new REST api.

• New features should ideally include updates(PR) to https://docs.mosip.io, including useful example code snippets.

• All submissions should have a changelog entry crediting the contributor and/or any individuals instrumental in identifying the problem.

Tests aren't optional

Any bugfix that doesn't include a test proving the existence of the bug being fixed, may be suspect. Ditto for new features that can't prove they actually work.

We've found that test-first development really helps make features better architected and identifies potential edge cases earlier instead of later. Writing tests before implementation is strongly encouraged.

Full example

Here's an example workflow for a project id-repository hosted on Github, which is currently in version 1.2.x. Your username is sasi and you're submitting a basic bugfix.

Preparing your Fork

1. Click 'Fork' on Github, creating e.g. sasi/id-repository. (choose to fork all the branches)

2. Clone your project: git clone https://github.com/sasi/id-repository.

3. cd id-repository

4. Add remote upstream git remote add upstream https://github.com/mosip/id-repository.git

5. Block push upstream git remote set-url upstream --push "Do not push"

6. git fetch upstream

7. Create a branch git branch <bugname or featurename> upstream/1.2.0

8. Setup the development requirements: mvn install -Dgpg.skip. You can use your favourite editor.

Making your Changes

1. Add changelog entry crediting yourself.

2. Write tests expecting the correct/fixed functionality; make sure they fail.

3. Hack, hack, hack.

4. Run tests again, making sure they dont break.

5. Ensure Sonar code coverage is same as before most of our repo’s have ensure >80%.

6. Commit your changes referring to Jira number in the commit message. Eg: git commit -m "[MOS-2346] Adding new upload feature in Pre-registration module for POA documents"

Creating Pull Requests

1. Push your commit to get it back up to your fork: git push origin 1.2.0

2. Visit your Github, click the handy "Contribute" button that it will make upon noticing your new branch and open a pull request.

3. In the description field, write down the issue number (if submitting code fixing an existing issue) or describe the issue + your fix (if submitting a wholly new bugfix).

4. Provide more details about the change to help the reviewers understand your point of view.

5. Hit 'submit'! And please be patient - the maintainers will get to you when they can. In case of urgency feel free to post in https://community.mosip.io

MOSIP releases would typically use two branches, namely develop and master. There is a also a third branch called release_branch that would be used to control the code check-in at the time of release.

Below is a description of each branch.

• master branch The master branch should always be production-ready. This means that any code that is committed into the master should have been tested before merging. Thus, anybody should be able to build and deploy a fully-tested code from the master. In other words, all MOSIP releases happen from the master branch.

• develop branch The develop branch is the active trunk and most of our development happens here. Developers make code changes on their private git repositories forked out of MOSIP repos. Their changes are raised as Pull Requests (PRs) which are carefully reviewed and merged into develop branch by one or more repo maintainers. At this point, it is easy to infer that several PRs flowing in may get merged in various repos. Automatic builds are triggered resulting in build executables (jars/Zips/EXEs) deployed on servers against which automated tests are run.

• release branch The release_x.x.x.x branch is the one on which final release development happens. Developers make code changes on their private git repositories forked out of MOSIP repos. Their changes are raised as Pull Requests (PRs) which are carefully reviewed and merged into release_x.x.x.x branch by one or more repo maintainers. At this point, it is easy to infer that several PRs flowing in may get merged in various repos. Automatic builds are triggered resulting in build executables (jars/Zips/EXEs) deployed on servers against which automated tests are run. Most often this is a final stage before release and unknown or unplanned PR's will not be accepted.

• feature branch The feature branch is created by a team when they need active development on a specific feature. Developers make code changes on their private git repositories forked out of MOSIP repos. Their changes are raised as Pull Requests (PRs) which are carefully reviewed and merged into feature branch by the respective feature owners. Automatic builds are triggered resulting in build executables (jars/Zips/EXEs) but not deployed on servers until the feature is adopted by MOSIP. These branches are not long-lived and would be deleted or cleaned up once the feature is complete or absolute.

Details

Continuous development happens on the develop branch where code is continuously merged as code contributions flow in on a daily basis. It is important that as and when the code gets developed, the corresponding tests also get developed in parallel so that both code and tests are merged together. This ensures that the tests that are run daily help in maintaining the sanctity of the code.

After a release_<version> branch cutover from develop the pom versions are changed to the next version with SNAPSHOT. This enables continuous development. The pom version in develop branch always has 3 digits separated by ".".

For e.g.: Let us assume develop-SNAPSHOT is the current POM version in develop (all POM versions are the same in a given repo.). When a release_1.2.0.1 release branch is cut, all the POM versions in the newly created branch are updated as 1.2.0.1-SNAPSHOT.

In MOSIP, we follow a four-digit version as 1.2.0.0. The branches are cut over for every version. So, the release_1.2.0.1 will have it's own branch and would be based on 1.2.0 or the latest of 1.2.0.x.

Feature branch

Major releases may be coded in the respective feature branches within the MOSIP subsystem. It may also be developed outside MOSIP in some other GitHub organization/repo. Once a feature is coded and is ready to be pulled into MOSIP, the organization or team could submit a PR. All feature branches are merged into the develop branch after the maintainer's review. Feature branches are deleted after their changes are adopted by the develop branch.

Release branch

When we are close to the code freeze, just before acceptance testing, the develop branch may be tagged and a new release_branch may be cutover. The release branch is meant for attaining stability through testing and bug fixing. After all the tests are successfully executed, the code is ready to be released. At this time two things happen:

• the code from the release branch is merged into master, tagged with the release number and released.

• the code from the release branch is merged back into develop branch.

To identify the actual release, you are requested to use the tag. The tags for a release follow the convention as v<release_version>.

Note: Please note the release branch name does not identify the actual release. While we try our best to keep it in line, there is no guarantee that the release would have happened from this same exact branch. The docker tags will match the release version. HELM chart maps multiple dockers from various repositories to the actual release version.

All the modified POM versions would be the same as the tagged release version.

Minor release

Minor release is needed to support te critical issues that are faced by customers. Customers may be using different MOSIP releases at any given point in time. While it is our goal to get our customers use the latest and greatest release, they may not be ready to upgrade and it is important to support the release they have deployed. At this point, two things could happen:

• the issue might have been fixed in the current code-base and might have to be back ported.

• the issue might have to be freshly fixed.

The following procedure must be adopted:

1. Identify all the supported versions of MOSIP.

2. Create a minor release branch from the latest release tag.

3. Checkout code, fix and test the issue.

4. Issue the release to the customer

5. Merge the fix into the develop branch so that it gets into the next main/ patch release. This step is followed on a need basis. There are several cases where this merge would not make sense as the design of the component may have changed in the upcoming releases.

The Go/No-go checklist delineates the criteria that must be satisfied for the project/ modules to be approved for release. It enables stakeholders to make informed decisions regarding the current status and progress of the release, as well as identify any gaps or missing items.

Also, separate pages for each stakeholder in the pre-release section needs to be updated before entering the summarized status below.

When the Final Consolidated Status for the release is Go, the release in done.

Overview

MOSIP is a product of the combined efforts of multiple stakeholders. Contributions from the community form the backbone of MOSIP and drive its growth and stability. The contributions have come in multiple ways, ranging from direct code contributions, review of design and architecture, bug fixing, and support for technology evaluation. In this section the MOSIP team would like to acknowledge the contributions of organisations and groups who have been instrumental in driving the project forward.

MOSIP partnered with LTIMindtree in August 2018 and since then it has been a fruitful association in areas of engineering, architecture, devops to name a few. Mindtree has contributed, through secondment of engineering resources, approximately 2260 person days of engineering effort, which roughly translates to more than 21000 person hours of work on the MOSIP project.

About LTIMindtree: A digital transformation and technology services company located in Bangalore.

The team at Technoforte has contributed multiple resources towards security testing, manual testing, automated testing, development, and devops. Technoforte has made significant contributions to the development of Partner Management Module, defining the partner policy, and setting up the partner portal. The team is also part of the community led effort of Android Reg Client development.

These valuable contributions were made by the Technoforte team with an approximate cumulative effort of about 4000+ person days which translates to 32000+ person hours.

About Technoforte: Technoforte Software Private Limited (Technoforte) is a Bangalore based firm engaged in providing enterprise solutions in the field of Information Technology.

With its belief in the open source values and the transformative power of Digital Public Goods Newlogic has been partnering with MOSIP in building the next generation of digital government infrastructures.

Newlogic regularly contributes to architecture, development, product management, and testing work.

Newlogic's contribution to MOSIP include:

• Integration of ID PASS Light library to generate and read encrypted QR Codes that allow offline identity sharing with biometric verification.

• Development of the Inji resident mobile app and its Minoto backend service.

• Development of a mobile credential sharing library that works both online and offline.

Singapore based Newlogic is a software consultancy company providing innovative software solutions to companies, organizations, and governments.

In 2022, Thoughtworks partnered with MOSIP as an engineering ally, embarking on a significant journey together. Key milestone was the creation of Tuvali, a BLE layer adhering to OpenID4VP standards. An alternate to Google Nearby, Tuvali facilitates the exchange of verifiable IDs across wallets and devices even without internet connectivity. This innovation empowers governments to effectively provide efficient and monitored citizen services.

Furthermore, the organization played a pivotal role in developing Inji Wallet, a digital VC wallet reference application. With a strong focus on security and inclusivity, Inji Wallet offers features for downloading, storing, managing, presenting, and verifying VCs within the MOSIP community. Built on OpenID4VCI standards, the wallet also includes data backup capabilities.

The organization has broadened its contributions to other essential components of the digital credentialing stack - Inji.

About Thoughtworks: Thoughtworks is a global technology consultancy renowned for integrating strategy, design, and engineering to foster digital innovation. With over 10,500 skilled professionals across 48 offices in 19 countries, the organization has a legacy of delivering impactful solutions for our clients over the past three decades. The company prides itself on leveraging technology to address complex business challenges and drive meaningful change.

Infosys began collaborating with MOSIP in Early 2023 as part of its Technology for good initiative. The company has been actively contributing to the development of the eSignet module, Android Registration Client, and other related modules. Through this pro bono collaboration, Infosys demonstrates its commitment to using technology for social good and empowering individuals with secure and reliable digital identities.

About Infosys: Infosys, a global leader in next-generation digital services and consulting, headquartered in Bengaluru, India, is a multinational corporation that provides business consulting, information technology, and outsourcing services to clients across the globe.

In January 2020, CyberPWN partnered with IIIT Bangalore to offer development assistance for MOSIP. Presently, CyberPWN's product engineering team, consisting of 30+ engineers, actively contributes expertise in multiple areas of MOSIP, encompassing Architecture, Product Management, Product Development, Quality Assurance, DevSecOps, Security, and Biometrics.

About CyberPWN: CyberPWN Technologies Private Limited is a respected cybersecurity consultancy and advisory firm. Leveraging their extensive expertise in the field, they collaborate with organizations to enhance their security posture, protect sensitive data, and counter cyber threats.

IIIT Bangalore has been home to MOSIP since its inception in 2018 and the students of the institute have been at the forefront of the MOSIP’s community-led development. The students have on an ongoing basis contributed to solving engineering problems in MOSIP for real-world applications. Their major ongoing contributions include:

Project 1: Reporting framework for real-time streaming of data and visualization. The dashboards give a visual display of metrics and important data to track the status of various pre and post-enrollment processes. Reporting framework involves setting up the data pipeline for populating data from the database to ElasticSearch.

A set of reference dashboards were also created as a part of this work.

Project 2: Registration officers/operators use the registration client application to enroll residents into the ID system. It is a thick client which works on machines with Windows OS.

Students have contributed to the development of Android equivalent of the Registration Client, which can be installed on Android tablets.

Project 3: Synthetic IRIS Data generation using ML algorithms

MOSIP test automation suite requires large set of synthetic biometric data such as IRIS. This project attempts to generate larger set of IRIS images from the given set of sample IRIS images. The solution is built using Guided-Diffusion with pre-trained models MOSIP USSD Proxy feature enhancements.

Project 4: MOSIP USSD Proxy feature enhancements

MOSIP USSD Proxy is a bridge between Telco SDP and MOSIP Instance. This allows to build custom USSD workflows.

The following workflows were developed under this project:

• Check registration status for a given RID

• Retrieve UIN Lock/Unlock status

• Lock or Unlock a given UIN

Protean partnered with MOSIP in September 2018 and since then the company has actively contributed in development and testing of various modules of MOSIP like Pre-Registration, Registration, Registration Processor, and other related modules.

So far, Protean has contributed approximately 1905 person per days of development effort, which roughly translates to more than 15000 person hours of work.

About Protean: Protean (NSDL e-Governance) offers digital ecosystem, curated to cater to billions. With over 25+ years providing unparalleled experience in creating population scale e-governance solutions, the company has empowered billions of lives across the country. Protean is building a digitised ecosystem for 1.4 billion people transforming citizen services for a better future.

The Sunbird community has developed 20+ digital solutions (called “building blocks”) which can be used individually or combined to create larger and more complex solutions. One of the building blocks, Sunbird RC has been used in the creation of Inji - a digital credentialing stack. The Sunbird RC team has actively led the development and contribution of a few components within Inji, such as Inji Certify, Inji Verify, and Inji Web.

About Sunbird: Sunbird is an open-source collective, seeded by the EkStep Foundation.

Preamble

MOSIP was created to foster an open, innovative, and inclusive community around open source & open standards. To clarify expected behavior in our communities we have adopted the Contributor Covenant. This code of conduct has been adopted by many other open source communities and we feel it expresses our values well.

Our Pledge

We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, caste, color, religion, or sexual identity and orientation.

We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community.

Our Standards

Examples of behavior that contributes to a positive environment for our community include:

• Demonstrating empathy and kindness toward other people

• Being respectful of differing opinions, viewpoints, and experiences

• Giving and gracefully accepting constructive feedback

• Accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience

• Focusing on what is best not just for us as individuals, but for the overall community

Examples of unacceptable behavior include:

• The use of sexualized language or imagery, and sexual attention or advances of any kind

• Trolling, insulting or derogatory comments, and personal or political attacks

• Public or private harassment

• Publishing others' private information, such as a physical or email address, without their explicit permission

• Other conduct that could reasonably be considered inappropriate in a professional setting

Enforcement Responsibilities

Community leaders are responsible for clarifying and enforcing our standards of acceptable behavior and will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful.

Community leaders have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned with this Code of Conduct and will communicate reasons for moderation decisions when appropriate.

Scope

This Code of Conduct applies within all community spaces and also applies when an individual is officially representing the community in public spaces. Examples of representing our community include using an official e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event.

Enforcement

All community leaders are obligated to respect the privacy and security of the reporter of any incident.

Enforcement Guidelines

Community leaders will follow these Community Impact Guidelines in determining the consequences for any action they deem in violation of this Code of Conduct:

1. Correction

Community Impact: Use of inappropriate language or other behavior deemed unprofessional or unwelcome in the community.

Consequence: A private, written warning from community leaders, providing clarity around the nature of the violation and an explanation of why the behavior was inappropriate. A public apology may be requested.

2. Warning

Community Impact: A violation through a single incident or series of actions.

Consequence: A warning with consequences for continued behavior. No interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, for a specified period of time. This includes avoiding interactions in community spaces as well as external channels like social media. Violating these terms may lead to a temporary or permanent ban.

3. Temporary Ban

Community Impact: A serious violation of community standards, including sustained inappropriate behavior.

Consequence: A temporary ban from any sort of interaction or public communication with the community for a specified period of time. No public or private interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, is allowed during this period. Violating these terms may lead to a permanent ban.

4. Permanent Ban

Community Impact: Demonstrating a pattern of violation of community standards, including sustained inappropriate behavior, harassment of an individual, or aggression toward or disparagement of classes of individuals.

Consequence: A permanent ban from any sort of public interaction within the community.

Attribution