{{toc}} The development of OpenAtlas depends on many factors and is very fluid. Here you find explanations of keywords and concepts used in planning. h1. Feature A feature is an isolated task. It can be a new functionality (e.g. an upload function for a logo), added functionality to an existing feature (e.g. adding new export formats) or a fix for a bug (e.g. repairing a button that isn't working as expected). Ideally, it should not take more than a week to implement one feature. If it is expected that a feature takes much longer, we try to break it up into smaller tasks. Features are either planned in meetings or requested by users. h1. Version The version naming scheme is "sequence-based":https://en.wikipedia.org/wiki/Software_versioning#Sequence-based_identifiers and reflects the significance: *major.minor.fix* e.g. *3.11.1* h2. Major The first number is raised rarely and symbolizes major changes and/or breaking changes. E.g. after the whole application was rewritten in a new language (from PHP to Python) the first number was raised from 2 to 3. h2. Minor The second number is the one that is raised most often. It includes a collection of features, typically around two to four, and should be doable in about a month. When a minor version is finished and uploaded to the productive systems it is also a good time to check how the development goes along and to make adaptations to the planning if needed. h2. Fix The third number is for fixing errors. Since we think that errors should be resolved as fast as possible we often don't want to wait a month for the next minor release, especially on productive system where people are working on their projects. These are quite infrequent depending on reported errors and their gravity. h1. Roadmap There are many feature requests (ideas for new functionality). Usually we plan ahead about three minor versions (around ten features, doable in about a quarter of a year) and call it the *"Roadmap":/projects/uni/roadmap*. The roadmap has to be flexible because of new projects or changed requirements of existing ones. E.g. new features are often beneficial for multiple projects and so the priorities can shift to reflect this. Many factors come into play when deciding which features are put onto the roadmap. One major factor are the requirements of projects who are financing the development of OpenAtlas but there are other factors as well like: * Availability of developers suited for specific tasks * Some features can have other features as prerequisites * Reported bugs have always the highest priority h1. Wishlist The wishlist is a special version in the roadmap. It is a collection of ideas and suggestions which we would like to implement in the future. In a new version we not only include critical features, but also try to implement features from the wishlist. The *"Roadmap":/projects/uni/roadmap* is accessible for the public so other projects or involved people can browse through it and identify features, which are imperative for their needs. If and when a feature is taken from the wishlist and included in a new version depends on several factors like funding, the usefulness for the projects’ majority, if features need prerequisites to be fulfilled, etc. It also can happen, that features which are already planned for the next versions are moved back to the wishlist, e.g. if it turns out to be much more time consuming than expected or if the project requesting that feature decides to change their own priorities.