L'équipe en charge des nouvelles versions a les responsabilités suivantes +:
+ +Mettre en place et publier le planning des versions officielles + du projet FreeBSD.
Documenter et formaliser les procédures de création des versions de manière à ce que + le processus soit constamment examiné et amélioré. Cela inclu + davantage de documentation à propos du cluster dédié aux ports et à propos des procédures + d'organisation des paquetages.
Mettre en place et publier les dates de "gel" du code source et jouer le rôle de + comité chargé de décider quels changements peuvent éventuellement être faits + durant ces laps de temps. Cela inclue les "gels" pour "HEAD" lors de la + préparation d'une version en .0 ainsi que les traditionnels + "gels" RELENG_* lors de la préparation d'une version -STABLE.
Création et maintenance des branches RELENG_* de l'arbre + src/. Cela inclu la prise de décision finale sur les changements + qui sont effectués (et qui resteront) dans la branche -STABLE avant la + mise en place de la nouvelle branche.
Travailler en coopération avec l'équipe principale et/ou la Fondation FreeBSD pour codifier un + ensemble de règles que les revendeurs doivent respecter pour être autorisés + à appeler un produit "FreeBSD" ou "Version officielle + FreeBSD".
Tester et intégrer les paquetages requis à partir de la collection + des ports sur le support (CD-Rom, ...) officiel choisi. Portmgr@ est + responsable de la gestion du "gel" des ports/ et + fourni l'ensemble des paquetages à partir des ports pouvant être redistribués. + re@ est également responsable de la répartition de ces paquetages sur les + différents ISOs en tenant compte des contraintes du support choisi. re@ est + l'ultime responsable pour veiller à ce que tous les paquetages + nécessaires soient disponibles sur le support choisi mais la coopération + de portmgr@ est essentiel.
Coordination avec le Projet de Documentation FreeBSD pour + s'assurer qu'un ensemble cohérent de documentations est fourni avec + la nouvelle version. Cela inclu la possibilité de demander qu'aucune + modification importante ne soit faite dans les documentations durant + les semaines qui précèdent la sortie d'une version.
Coordination avec l'équipe de l'officier de sécurité afin de s'assurer que + les versions FreeBSD en cours de création ne sont pas affectées par des failles de + sécurité récemment découvertes. De plus, approximativement une semaine après la sortie d'une version, + la responsabilité de l'approbation des modifications sur la branche RELENG_X_Y + est transférée de l'équipe en charge des versions à l'équipe en charge de la + sécurité. La date exacte du transfert est choisie en commun accord entre les + deux parties une fois qu'il est clair que la nouvelle version est un succès. Une annonce + est alors envoyée sur la liste developers@.
Envoyer des messages sur announce@FreeBSD.org au nom du + projet pour annoncer les nouvelles versions de FreeBSD.