Home

Welcome to the super-fields wiki!

How to submit issues

Bugs

If you find that something does not work as it should - or you think it should - please do the following:

• read the documentation (JavaDocs and this wiki) to make sure that it indeed is a bug, not some quirky (but expected) behaviour;
• head on to issues and see if any of the open issues deals with the same or similar bug, and if not - please file a new one.

When reporting a bug, please include the following:

• information about what you did, ideally attach screenshots and/or code snippets, and what component you used, together with its version and Vaadin version; in general, please provide rather more information that not enough;
• what happened (what was the observed result);
• what should have happened (what was the expected result) - you can omit this part if it is obvious from the context of the ticket;
• please label the ticket as bug; the ticketing system of GitHub is the main communication channel, so keep an eye on your ticket.

Feature requests

If you would like to have a feature that is not currently in development by Vaadin, feel free to suggest it by filing a new issue and labelling it as enhancement. Please be descriptive, attach screenshots, mockups, use cases, etc.

Releases

Releases to Vaadin Directory are done by hand. Releases to GitHub are (almost) fully automatic, as are releases to Maven Central.

Code quality and repository structure

The repository is structured so that:

• master branch is used only for releases, with each release having its tag there;
• development branch is the default branch; code there should pass tests, but there may be bugs or issues open; it is protected from pushes - only PRs;
• ticket branches are for work, they should be named according to the ticket(s) they refer to: NUMBER-scope (e.g. 100-automated-versions);
• java-8 branch is for maintaining backwards compatibility with Java 8 and Vaadin 14; from time to time the code from master will be merged into that branch, fixed, pushed and then released as a corresponding -vaadin14 version.

Code quality:

• write good code - document methods, especially non-private ones; use interfaces, avoid duplications, make code readable, use comments, etc.
• write tests - for things that cannot be tested through Karibu or unit tests, make sure the code works and be sure to update the demo app to include it, and try it out before making a PR.