This repository –whether a software project, design guide, or other, also called 'component’– is part of the GeneXus Suite, a set of products to simplify application development whose main features include being multi-platform (for more information, read the GeneXus Suite section). In this context, all contributions made are intended to enhance the user experience of these products or the applications generated.
It is licensed under Apache 2.0, so all contributions must comply with this licensing.
To ask questions directly about the way this component works, you can post them in the open forum for the Beta channel: for example, questions about a new functionality, topics that may be in the product roadmap. For more details, read the Resources section from the Forums option.
Clearly indicate the component in question using the repository name when asking questions.
If you are not a member of the community yet, we invite you to join us and make your contributions from the different forums (in addition to the Beta channel forum there are specific ones for some technologies). The GeneXus Team and the entire community will be there to help.
You can also visit the GeneXus Wiki, where you will find all the relevant documentation, current developments, and contributions made by the community.
To be accepted, contributions must involve:
- An incident fix (either an error correction or code enhancement),
- Improving the extensibility and/or
- Completeness of the component. Basically, contributions must not substantially change the existing functionality and must be useful for any of the GeneXus Suite products or generated applications.
Contributions are accepted in the 'master’ branch. There are other branches defined in the repositories but no contributions will be accepted in them (there is detailed information about them later on in the Branches section).
Every contribution must have an associated incident. An “incident” is a report that describes the problem found and how to reproduce it.
The first step is to review the status of incidents already reported, which helps to enhance your communication with the team responsible for the component, avoiding duplicate reporting of issues or even reporting an already corrected issue; each incident provides information about its current process status.
If the incident has been reported and its correction is pending, keep the incident number for future reference when the solution is available.
If no report of the incident is found, it may have been solved as a result of the evolution of the component itself.
Try to reproduce the issue using the ‘master’ version of the component.
A discussion has been specifically opened for GeneXus-generated applications (one of the products of the Suite), since several of the organization's components are integrated into the applications generated by this product.
For these applications, we recommend re-generating them with the latest stable version of GeneXus available in the Preview channel of this product.
To do so:
- Download and install GeneXus from the Preview channel.
- If the knowledge base is not stored in a GXserver, back up the .mdf file.
- Run GeneXus.
- If the knowledge base is stored in a GXserver, you should make a checkout and try a clean version; otherwise, open the knowledge base.
- Run a Rebuild All of the knowledge base.
- Test the application built with this version and check if the issue is reproduced.
To make a good report, certain information must be included:
- Description of the issue indicating the functionality that doesn’t achieve the expected performance.
- Sample code showing the use case that doesn’t work as desired.
- About running an application generated with GeneXus, include the following:
- GeneXus version used to develop it;
- System details (OS version, version of SQL Server used to store the knowledge base, details of the compiler used by the generator, etc.);
- Characteristics of the knowledge base (generator used, database configured and its version);
- Whether MSBuild Tasks are being used (creating a continuous integration cycle) or from one of the available IDEs (indicate which one);
- Add an XPZ with which the issue can be reproduced when creating a new KB. In some cases, this XPZ is not easy to create, but it certainly increases the possibility of having the fix approved.
Improvements to the component itself can be reported through GitHub issues, if the repository has this option enabled. This report must be submitted in English.
For issues related to the integration of this component with GeneXus, an incident must be entered through the SAC Issue Tracking system (you will need a GeneXus Account to do so).
The Fork and Pull Request (PR) mechanisms provided by GitHub are used to make a contribution.
GitHub provides some useful guides to get started: Getting Started with GitHub there you will find how to initialize the development environment to use GitHub, as well as how to create a Fork and work with a Pull Request.
- Create a Fork of the project on which you want to collaborate.
- Make changes to the project in its version.
- When the code is built without any new errors or warnings,
- And tested, you can integrate it into the main repository.
- Make a PR.
This PR will be pending audit by repository managers within the organization. The result can be as follows:
- Approved, in which case the changes are integrated into the organization's repository;
- Request for improvements or changes to the PR;
- Rejected.
This result depends on the next process to be carried out by those responsible for the component (failure of any of these steps will imply a possible rejection of the PR or the request for improvements to it):
- Confirm that there is an incident associated with the PR.
- Try to reproduce the issue in the ‘master’ branch.
- Build and integrate the PR and check that the error obtained in the previous step has been corrected.
- Run an integration test.
- Check that the project’s style guidelines have been followed.
- Approve the PR.
Some of these steps depend on good and effective communication with the team in charge. Read the next section for suggestions on the matter.
- There can be no project build errors (when you make a 'Git Checkout’ + PR build, confirm that the result is error-free).
- As for the PR comment, it should:
- Be in English,
- Define a title that describes the problem,
- Include the incident number (depending on the system in which it has been reported, it will be an IT/SAC or GitHub Issue number),
- Include additional information to help understand the need for the change and how to prove it, especially if the incident information is incomplete (review the section Report an incident to make sure that you have all the necessary information).
- A PR must solve a single incident.
Accepted contributions will first be included in the GeneXus Suite Beta channel; after the corresponding validation and test processes, they will be incorporated into the Preview channel from which they will be released in the next version.
They refer to the following set of products:
- GeneXus, a code generation tool.
- GeneXus Server, a tool for team collaboration.
- GeneXus BPM for process modeling, automation, management, and optimization.
- GeneXus Query for reporting and data analysis.
- GXportal for creating websites.
| Resource | Description |
|---|---|
| SAC | System to query reported and corrected incidents. |
| Issue Tracking | System for reporting incidents related to GeneXus (a GeneXus Account is required). |
| Wiki | Where to search the documentation for different GeneXus products, contributions from community members and the latest developments. |
| Search | Searches in all of the organization’s public resources (those mentioned above and some others). |
| StackOverflow | Accessing the Preview or Beta channels is recommended (a GeneXus Account is required). |
The following well-defined branches can be found within a repository:
master: stable development version (its functionality and integration with GeneXus has been tested).beta: development version that integrates the different pull requests made from feature branches in order to test their functionality and integration with GeneXus; it is unstable by definition.release-*: stable versions that have been released together with a GeneXus version; published releases emerge from these branches.- All other branches are known as 'feature branches.' That is to say, branches where specific developments (features or fixes) are being made; they are deleted after they are merged into a 'master' branch.