Le 18/08/2017 à 11:51, Guilhem
Bonnefille a écrit :
IMHO, external users should not be interested in using the branches develop of feature-*. If so, we can imagine that the real problem is the lack of intermediate public versions. +1 2013-04-24: Orekit 6.0 released with a lot of new features | | +233 days (~8 months) V 2013-12-13: Orekit 6.1 released with a lot of new features | | +394 days (~13 months) V 2015-01-11: Orekit 7.0 released with a lot of new features | | +392 days (~13 months) V 2016-02-07: Orekit 7.1 released with a lot of new features | | +98 days (~ 3 months) V 2016-05-16: Orekit 7.2 released | | +44 days (~ 1 month) V 2016-06-29: Orekit 8.0 released with a lot of new features | | +392 days (~13 months) V 2017-07-26: Orekit 9.0 released with a lot of new features And, as orekit has a lot of good practices around tests and quality, gitflow is certainly the last piece of organisation allowing frequent releases for quite nul effort. +1 Probably that the most boring and thankless part of the release process is the synchronization of the website and, above all, the wiki: information must be partially duplicated but the formatting dialects are different. May be that another approach would be preferable, especially for the wiki. Sébastien -- Sébastien Dinot Free Software Expert CS SI - Space BU - Payload, Data & Applications Parc de la Grande Plaine - 5, rue Brindejonc des Moulinais - BP 15872 31506 Toulouse Cedex 05 - France +33 (0)5 61 17 64 48 - sebastien.dinot@c-s.fr |