Quelles sont les meilleures pratiques pour la publication d'un projet open source?

Question

Nous avons un petit framework web assez cool que nous avons utilisé avec succès sur des dizaines de projets clients. Nous prévoyons de mettre ce logiciel à la disposition de la communauté. Cependant, je me tords la main sur ce qui devrait/ne devrait pas aller sur une nouvelle page de projet de logiciel open source. Quelles sont les choses que le site doit avoir? Docs? Un wiki? Un lien pour télécharger? Quoi d'autre?

Et, une question connexe, mais peut-être différente, est de savoir comment commencer à marquer les numéros de version. Tout ce que nous utilisons en interne est le tampon SVN. Est-il un bon moyen de déterminer quand commencer à appeler quelque chose de la version 0.9 par rapport à 1.0 et 1.1 et ainsi de suite?

Answer 1

Vous pouvez avoir une idée de ce qui est requis par ce projet open source sites d'hébergement offrent:

• Un site Web qui fait office de « guichet unique » pour le projet
• Docs, potentiellement wiki forme
• Un référentiel source permettant la navigation, la caisse anonyme et authentifiée et autorisée engage
• suivi de l'émission et nouvelle demande de nouvelles fonctionnalités

En ce qui concerne les numéros de version ... Je ne pense pas quelqu'un de a travaillé la meilleure façon de le faire encore :) Avec un minimum de pensée, je considérerais:

• v1.0 devrait être prêt pour l'utilisation de production
• Les modifications majeures de numéro de version peuvent complètement perdre la compatibilité ascendante (si nécessaire - pas vraiment un but!)
• Les modifications de numéro de version mineures devraient être généralement compatibles - la dépréciation est probablement meilleure que la suppression/le changement de nom des bits de API
• Plus petite que la mineure les modifications du nombre d'ions ne doivent inclure que des ajouts fonctionnels mineurs (le cas échéant) et des correctifs de bogues/performances

Answer 2

L'étiquetage de la version 0.9/1.0/1.1/1.0.1/... est à des fins de marketing uniquement (dans le bon sens du terme). Cela permet à vos utilisateurs/clients d'identifier si la version est majeure, mineure ou corrective et si vous la considérez mature ou pas encore.

Le minimum à livrer est les sources. D'autres livrables dépendent de la façon dont vous êtes prêt à aider vos utilisateurs et à leur fournir un soutien.

Answer 3

Jetez un oeil à GitHub ou Google Code. ils constituent un très bon point de départ pour vos propres projets open source. Vous pouvez décrire votre projet, documenter dans un wiki, utiliser git ou svn comme référentiel, et fournir des téléchargements avec un suivi de problème et une gestion multi-développeur. De beaux environnements prêts à l'emploi pour apprendre et les utiliser.

Pour les numéros de version: je ne recommande pas 0.9 ou quelque chose comme ça pour les pré-versions. La raison? Qu'en est-il de la version 1.9? Est-ce la 9e sous-version de la version majeure 1 ou est-ce la dernière version préliminaire de la version 2? Ma norme de version est décrite ici: http://code.google.com/p/tideland-eas/wiki/ReleaseStandard. J'utilise un schéma à trois nombres, majeur, mineur et correctif, avec un code d'état, alpha, bêta, gamma et la date de sortie. Je suis donc capable de gérer plusieurs versions en parallèle facilement.

Espérons que cela aide.

Mue

Answer 4

Choisissez un site pour accueillir la source sur la première (SourceForge, par exemple). Obtenez la source là-bas sur un système de contrôle de version avec caisse anonyme. Obtenez une adresse e-mail là-bas pour les personnes à vous contacter.

Appelez cette première version 0.1. C'est parce que vous n'avez pas encore de document pour soutenir le projet.

Respirez ensuite. Puis commencez à regarder la documentation, comme un wiki. Une fois que vous avez tout couvert, à un niveau de détail de base, et vous croyez que la version est prête pour une prime time, alors passez à la version 1.0, et commencez à fournir des téléchargements binaires.

Answer 5

Assurez-vous de penser à la licence pour les sources.

Lorsque je regarde un projet open source, l'une des premières choses que je vérifie est la licence. Si la licence n'est pas GPL2/GPL3/BSD styles ou similaire, c'est un démotivant pour moi. La licence signifie ce que les gens vont faire avec, comment il peut grandir, et combien il est détenu par l'entreprise qui l'a publié. En choisissant l'open source, j'essaie de ne pas dépendre des entreprises (qui dépendent de leurs actionnaires), je choisis vraiment d'utiliser le logiciel qui est vraiment gratuit. Comme la communauté open source est très sensible au pouvoir des entreprises (Google semble un peu à l'abri de cela en ce moment), vous devez donc vous assurer de livrer le message de vraiment gratuit sur votre site web et d'autres matériaux vous libérez sur le logiciel. Voir plus sur free software et open source définitions de la FSF.

Answer 6

Sur la gestion des versions, je pense que le meilleur endroit pour commencer est Semantic Versioning.