Naming

Names in code

As well as following the Go code style and our file format organisation mentioned above it is also important for code contributions to match our naming scheme. This makes code easier to read in the future and, for public APIs, helps with discoverability and documentation as well.

The following aspects of naming will be checked during a review process (assuming the basic "golint" has already passed):

• Naming should be clear and spelled using US English
• Names should be unambiguous but not too long, full words are normally preferred with a few exceptions (such as 'a' for fyne.App or 'w' for a fyne.Window)
• Public types should have a constructor function with prefix "New...", this function should take the parameters of elements required for a well functioning object.
• Although optional items should not appear in constructors, a particularly common usage of some parameters could be presented through additional constructors, using a "With..." suffix, like "NewButtonWithIcon".
• Enum types (groups of consts using iota) should have a named type and would normally add this type name as a prefix for namespacing
• Callback functions that can be set by external developers should be prefixed with "On..." and use the past tense, for example "OnTapped" or "OnChanged"

Version naming

Release artefacts

Fyne broadly follows a semver approach - our releases are numbered vx.y.z where:

• We will increment x if a release will contain breaking API changes (a major release)
• API additions and non-breaking public changes will cause a y increment (a minor release)
• All other versions will increment z (a patch release)

API numbering

Because APIs should not change between minor releases (see above) we follow a shorthand for referring to an API number. This allows us to use shorter numbers in our marketing and in URLs for API documentation.

Future releases

When planning we will try to avoid focus on which version number comes next by using code names. In planning sessions we will pick a codename to refer to the future release and the actual version number will be chosen according to the rules above once we know the scope of the release. During work on any major or minor releases we will continue to release regular patch releases as and when reqired, incrementing the z component of the full version number.