Am 10.12.2010 17:09, schrieb DEGREMONT Aurelien: > nap a écrit : >> For each big feature, we can increment the version (0.4.1, 0.4.2, >> etc). So it will be easier for testers to know which version they got :) > I think this is not a good idea. > For a lot of people, changing the revision version means only security > fixes and bugfixes -> small changes. > Bigger changes is related to major or minor. (see http://semver.org/) > If you really have a new big feature, change to 0.5 or 0.6, ... I agree with Aurelien. Minor versions (3rd position) should only be used for bug fixes and security fixed. Feature changes and major code changes should
This is what many, many project do, e.G. OpenBSD. And this is what I would expect, too. Further I propose the Release Policy to be published in the wiki, as Tryton did: <http://code.google.com/p/tryton/wiki/ReleaseGeneral> -- Schönen Gruß - Regards Hartmut Goebel Dipl.-Informatiker (univ.), CISSP, CSSLP Goebel Consult Spezialist für IT-Sicherheit in komplexen Umgebungen http://www.goebel-consult.de Monatliche Kolumne: http://www.cissp-gefluester.de/ Goebel Consult mit Mitglied bei http://www.7-it.de
smime.p7s
Description: S/MIME Cryptographic Signature
------------------------------------------------------------------------------ Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL, new data types, scalar functions, improved concurrency, built-in packages, OCI, SQL*Plus, data movement tools, best practices and more. http://p.sf.net/sfu/oracle-sfdev2dev
_______________________________________________ Shinken-devel mailing list Shinken-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shinken-devel
