[rudder-dev] adding feature to a technique

Jonathan Clarke jonathan.clarke at normation.com
Sun Feb 3 13:56:14 CET 2013


On 03/02/13 13:14, Michael Gliwinski wrote:
> Hi all,

Hi Michael,

> Just a quick question about the process for adding features to a technique.  
> How do you decide if a new version (major/minor) of a technique should be 
> created for a feature?

This is currently a bit of blurred definition. Until now, we have always
said that bug fixes in Techniques should be applied to all versions,
with no version increment (ie, if a bug is in version 1.1, we fix it in
1.1, without incrementing it). This is not a great approach IMO, since
versioned software/code/whatever should never change. The reason we did
it this way was to make sure that Rudder users got bug fixes as soon as
they are available.

In the future, I would like to move to a clearer versioning policy. This
remains to be discussed, and hopefully this email can be a start to the
discussion, but here's what I was thinking:

  * Minor version increments should be for bug fixes (ie, in the example
    above, a bug in 1.1 would be fixed in 1.2)
  * New features would require a major version increment. So, a new
    feature in a Technique in version 1.1 would be implemented in 2.0.
  * By default, Rudder would automatically use the latest minor version
    given a major version. So if I'm using a Technique in version 1.*,
    currently 1.1, and 1.2 is available, Directives are automatically
    upgraded to 1.2.
      o This behaviour should be disable-able on a per Directive basis,
        and on a global basis, to enable "freezes" such as exist in many
        companies.
      o This also means that minor versions could not introduce new
        variables (or change constraints on existing variables).

What do you think about this versioning policy, everyone?

> I've a small addition to fileManagement, to allow maintaining local copies of 
> files (needed that in some cases where dropping a symlink wouldn't work for 
> security reasons, e.g. cron.d files).
>
> So far I patched version 1.0 which works OK for me, but I wanted to submit it 
> :)

Sounds great! I must buy you a beer ;-)

So for this particular case, I would suggest submitting a new major
version, because this is quite a significant improvement, and would fit
with this new versioning policy if we adopt it. To submit, the preffered
approach is to use a GitHub Pull Request.

Jonathan
-- 
------------------------------------------------------------------------
*Jonathan CLARKE*
/CTO - Directeur technique/
Normation <http://www.normation.com>
------------------------------------------------------------------------
*87 rue de Turbigo, 75003 Paris, France*
Telephone: 	+33 (0)1 83 62 41 24
Mobile: 	+33 (0)6 99 60 03 10
------------------------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.rudder-project.org/pipermail/rudder-dev/attachments/20130203/7daacc40/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logo-square.png
Type: image/png
Size: 3503 bytes
Desc: not available
URL: <http://www.rudder-project.org/pipermail/rudder-dev/attachments/20130203/7daacc40/attachment.png>


More information about the rudder-dev mailing list